Search Results

In business, the quest for predictability is universal. We all want to grab hold of the reality we face everyday and, somehow, bend it to our will. When we are surprised by the unexpected, we often assume that we have failed in some way. We have this underlying belief that if we just do our job well enough, we can prevent any and all surprises and that success will follow. Unfortunately, that’s nothing more than a nice fairy tale. In real life, we have no hope of overcoming all uncertainty — zero. Instead, we must begin to accept it and learn how to operate, even thrive, within it. But we can’t do any of that if we don’t try to understand it. Stephen Bungay, the author of The Art of Action, helps us understand the shape of our uncertainty by expressing it via something he calls “the three gaps.” These gaps are places where uncertainty shows up: The Knowledge Gap: the difference between what we’d like to know and what we actually know. This gap occurs when you’re trying to plan, but often only manifests when you are trying to execute the plan. Often, we try to combat this gap, not by doing something different than before, but by doubling down on what we’ve already done. In other words, we just didn’t do it well enough the first time. So, instead of accepting that we may never know everything we’ll need to know up front, we double down on detailed plans and estimates. The Alignment Gap: the difference between what we want people to do and what they actually do. This gap occurs during execution. Like with the knowledge gap, we try to fix it by doubling down. In this case we double down on providing more detailed instructions and requirements. We are quite arrogant in our thinking and believe that if we can just be more thoughtful and more detailed, we can prevent all surprises. The Effects Gap: the difference between what we expect our actions to achieve and what they actually achieve. This gap occurs during verification. We don’t often consider that, in a complex environment, you can do the same thing over and over and get different outcomes despite your best efforts. Instead, we think we just didn’t have enough controls. We are stubborn to the point of stupidness and continue to think that we can manage our way to uncertainty. A most excellent example of how we like to try to overcome the gaps! by Jim Benson The ugly truth By reinforcing the idea that you can control your way to certainty, you aren’t teaching people how to be resilient and how to operate despite what comes their way. This means that when surprises do sneak through, people will be woefully unprepared and, more often than not, efforts will start to veer towards blaming the responsible party instead of figuring out a way forward. The ugly truth that we all must face is that, in complex environments like software development, healthcare, social work, product development, marketing, and more — we will never defeat uncertainty. To be honest, we wouldn’t like what would happen if we did. It would be the end of learning and innovation. So, what now then? While we have to accept that some uncertainty will always remain, we can try to tackle the low hanging fruit. For instance, we don’t abandon all research or planning. We just accept that things may not always go to plan and have an idea of how we’d react when uncertainty pops up. When I managed the web development team for NBA.com, we would run drills for our major events like the Draft and walk through scenarios like “What happens if a team drafts someone we don’t have a bio for?” and “What will we do if our stats engine breaks down?”We accepted that because we can’t control everything, the skill that we really need to survive in business is resiliency. We needed to learn to anticipate, react and recover. We learned how to think about resiliency and build it into our work processes, not just our technical systems. So, if you are finally getting to the point of accepting that you can’t conquer uncertainty, the next mission is to begin to build the skills of resiliency. There is no comprehensive list of ways to become resilient but I’ll share a few things I use while working in an uncertain environment. The Agile Manifesto The Agile manifesto is an excellent embrace of uncertainty and a pushback against our natural tendencies when reacting to Bungay’s three gaps. While there is a place for plans, documentation, contracts, and processes they are not the only, or even most important, things we need to excel in uncertain environments. The Scrum Framework One of the biggest benefits to the scrum framework is that sprints act as a forcing function to work in small batches. If you work in a smaller batch you notice the gaps more quickly and, if you fall prey to those natural tendencies to double down on instruction and planning, you’ll do so in a smaller way and, hopefully, learn more before the next piece of work starts. This is a perfect example of accepting uncertainty and trying to limit the potential damage. Kanban and Limiting Work-In-Progress Adopting Kanban forces you to limit the amount of work going on at one time. This has a similar benefit to the Scrum framework, but at an even more granular level. While Scrum limits how much you start in a Sprint, Kanban limits how much you have in progress at any one time. Thinking of your work-in-progress in economic terms can really help you understand the value of limiting it. My friend and generally awesome person, Cat Swetel, once said that you can think of your work falling into three buckets: Options  -  work not started Liabilities  - work in progress Assets  - work already finished It is in our liabilities that we are subject to the effects of uncertainty. If we limit the potential impact to a manageable amount, we limit the possible damage and, more often than not, we turn liabilities into assets faster. Probabilistic forecasting Often, even though we know there are many potential outcomes, we still provide a single forecast. A better way, that visualizes existing uncertainty, is to give forecasts AND state the likelihood that a particular forecast will occur. You’re very familiar with this whether you realize it or not. Every weather forecast you’ve seen uses this approach. Doing this is easy. You can use your historical data to forecast probable outcomes with cycle time scatterplots (for single items) or monte carlo simulations (for a group of items). Wrapping it up No matter what you choose to do going forward, by far the most important choice you can make is to accept the inevitability of uncertainty and to commit to learning how to thrive in the face of it. Sharing stories of your successes and failures helps both yourself and those who hear or read them to widen their perspectives. Having to tell the story makes you synthesize the information and make conclusions so that you understand what happened enough to tell the tale. And, while your context will not likely perfectly match that of your readers or listeners, it may provide them perspective and information that they can incorporate into their hypotheses.

Our customer, Redox, tells their story This is part one of Redox’s four-part “Contingency Planning During a Pandemic” series. It was authored by Morgen Donovan and is republished here with permission. Check out part two / part three / part four on the Redox blog. I had the good fortune of already working from home for a distributed company when COVID-19 struck. As the virus began to impact life as we knew it, I looked around and saw how other companies struggled to transition to a remote workforce. While all Redoxers felt the abrupt effects of COVID-19 social changes, because we were already working from home we had a leg up in responding to the impending crisis. We quickly began shifting our priorities to adjust to what may very well become a new normal. As we did this, we also realized we wanted to share our experiences, as other companies surely are or will be attempting some similar efforts. My hope is that this series, from a remote-first perspective, will help some of you who are facing the same challenges. The focus will be to expose our process and results clearly, and whenever possible, my co-writers and I will offer suggestions for alternative tools or methods to replace some of our own. Planning for the unexpected As cities and states began going into lockdown and the world had to start thinking about what to do when schools close or loved ones became sick, we realized we didn’t have a solid system in place for contingency planning around individual workload. Who would take over for me if I was out unexpectedly for two weeks, and would they know what to do? we wondered. And how could we tap into the capacity demands of each team and watch as it shifted throughout this crisis, so we would know where to focus our attention and provide help? There was a lot to do; we would need an army. So in a joint effort between the People Operations and Operations teams, Dietke Fowler, our director of Business Operations, and I enlisted the help of every HR recruiter plus our Knowledge Manager to get the ball rolling. We packaged all of the projected work into a single project, which we launched on March 26 and concluded on April 15. We kicked the project off with some goals already identified. We needed to: Implement a method for maintaining a current understanding of our capacity 2. Address potential capacity imbalances by: Identifying who has capacity and can help out in other areas Identifying who does not have capacity and needs help Shifting help to where it’s needed 3. Build resilience into teams through: Ensuring backups are in place for all work functions Documenting and storing our knowledge and processes in an easily accessible place From these goals, we built out some key deliverables we thought would get us to our desired end state. The deliverables evolved as we worked through our project, some becoming absorbed by others or outscoped, with some new needs arising. Here’s where we landed: Launch weekly capacity pulse checks that can be reported out by team and role. Create a virtual Help Desk that allows Redoxers to post their needs, help-wanted style, and lets other Redoxers offer up their help. Implement individual contingency plans that identify who is working on what, backups for that work, and whether the work does or does not have process documentation already in place. In this post, I’ll talk about our first deliverable, the work we did to achieve it, and its outcome. Each following post will dive into the remaining deliverables. Deliverable №1: Implement regular capacity pulse checks The work We wanted to send out surveys every Monday, and because they had a three-day turnaround they had to be short, with a low barrier to entry. We needed to be able to filter our results down by team and generate data on capacity, when considering factors both internal and external to work, as well as cognitive load. We used a Google form* and kept it simple. The first component of the survey checks stress levels on a 5-point agree/disagree scale: My own stress, worry, or general cognitive load is negatively affecting my ability to complete my work. Situations external to Redox, such as caring for children or other family needs, are negatively affecting my work capacity. Situations internal to Redox, such as disruptions to my team/other Redoxer outages are negatively affecting my work capacity. The second component asked Redoxers to compare their current work capacity (availability and presence) to their capacity prior to the COVID-19 pandemic using a scale of 0 to 10 (where 0 represents “no capacity,” and 10 represents “still at 100% capacity”). Finally, we asked Redoxers to compare the current demand for their time against the demand prior to the COVID-19 pandemic using a scale of 1 to 5 (where 1 represents strongly decreased and 5 represents strongly increased). We launched our first survey on March 30th via email to every Redoxer with a follow-up post in our “important-only” slack channel. That same evening, our CEO, Luke Bonney, asked all of us in his video address to complete the survey. This crucial component of our messaging effectively told all that this high priority effort required everyone’s participation. As the results came in, we fed the data into Chartio, linking the email addresses of respondents from the Google form with demographic data from our human resources information system (department, subteam, coach, location). The resulting dataset served up various charts on a dashboard that displayed the survey results graphically as well as in plain language. The dashboard could be filtered down by team, coach (manager), and status of response (responded or not responded). While we used SQL in Chartio to join the survey data with our team directory, you could also use visual dataset builders or SQL in other data visualization tools, or even VLOOKUPS in MS Excel or Google sheets. The result By Thursday of that first survey week, we had achieved 89% participation companywide, and we were pleasantly surprised by this level of engagement. The results were surprising as well — they told us that the average impact of COVID-19 on our capacity wasn’t as drastic as we had originally estimated. Redoxers were reporting that situations internal and external to Redox were having a moderate impact on their work capacity, and their general cognitive load was adding an additional moderate level of impact. On the upside, there was only a little more work to do on average. For the first week, these results were reassuring and provided us with a good baseline to track against in the upcoming weeks and months as the pandemic’s effects continue to evolve. In addition to company-wide metrics, we also created visualizations that compared departments across the company. This allowed us to pay special attention to departments that were feeling the most impact. The plan was to survey our team weekly, but Redoxers reported that they were already experiencing some survey fatigue (there’d been a few other surveys launched in the previous two weeks). After some consideration, we decided that biweekly would get the job done just as well, and our CEO again communicated this new plan to the company. We are incredibly fortunate to have our Knowledge manager, Jessica, working tirelessly to get each of us documenting our knowledge and work processes. Going forward, she will review the biweekly results and reach out to teams most in need to determine if she or others can help them reach knowledge management goals. For teams needing help beyond that scope, we created a brand-new resource to make it easy to ask for and receive assistance — the Help Desk, which Becky will talk about in our next post for this series, so stay tuned! As we all continue to work through a challenge most of us have never experienced in our lifetimes, let’s keep up this culture of educating each other, and continue to lean on one another for support. Note from Morgen @ Redox: We chose this over our regular survey platform Culture Amp, as we didn’t want to overuse and diminish the future effectiveness of this powerful tool. Your organization might prefer a different way to manage surveying.

ActionableAgile connects directly to Jira, Trello and Azure DevOps Services so that you can connect to your data with zero hassle. However, if you want to analyze data from other systems or simply don’t want to use the built-in data loaders, you can manually upload your data! The options available to you depend on which version of ActionableAgile you’re using. In the table below, click the links to read detailed specifications about file formats, get tips, and see templates and example files for each available option. No matter how you load data into into ActionableAgile, you can feel secure knowing that we never store your data. All of your important information stays in your browser.

We all want to design our Kanban boards to enable consistent, smooth flow of work all the way from start to finish. Unfortunately, that capability doesn’t come naturally and the way we often visualize our work processes can unknowingly cause dysfunction. In this post, we share some important things to consider (at least from our experience) when you want to design your board to enable great flow. Focus on the work, not the workers Do the column names of your board sound like the titles of the people in your team? Do you, or others in your team, often work in just one column of your board? If so, your board design might be built for resource efficiency instead of flow efficiency. Resource efficiency is making sure that every individual person (in this case) is always busy – often at the cost of completing work. Flow efficiency is a focus on making sure that the path is easy and clear for work moving through a workflow. A team that focuses on flow efficiency encourages collective ownership of work from start to finish. A team that focuses on resource efficiency tosses work over proverbial walls to the next column and moves onto something else without looking back (or forwards, in this case). A desire for flow efficiency doesn’t mean that everyone has to be assigned to everything all the time. Even when there is a primary assignee, a team is collectively responsible for getting work completed and team members may need to work on items in multiple columns at one time. These practices will put a priority on team performance over individual performance. Purposefully handling cyclical activities If your board is built with too much granularity, team members can be confused about what to do when they experience the cyclical portions of your process. Let’s tackle the most talked about scenario – testing! Let’s imagine the team has a column on their board called Executing followed by a Validating column. The team’s policy is that an item moves from Executing to Validating when it is ready for external review. The team recognizes that bugs will be found during validation from time to time. If the team doesn’t talk about how to handle the discovery of bugs when work is in the Validating column, they may think that the best course of action is to move it back to the Executing column (and repeat this process as many times as it takes.) Unfortunately, moving cards backwards causes us to lose visibility and data. (Read about the impact of backwards flow on data.) Instead, the team can take steps to better accommodate this expected cycle. One option is to keep all cards in Validating until all found bugs are fixed. If they want to separate the initial validation from subsequent fixes, they can create a new column to the right of Validating called Fixing. Now when bugs are found, cards move there until are all fixed. The good thing about both of these choices is that data is preserved. We can still measure the original time spent in Executing AND tell how long it takes to complete since it first entered Validating. Separate activity from wait In order to really focus on improving the flow of work through your system, you will want to visualize when work is actively being worked on versus when work is ready and waiting for attention. This allows you to see important things like: bottlenecks in different stages of the workflow as seen by large queues directly to the left unreasonable amounts of work sitting in active column, masking additional wait time whether or not you should focus on reducing wait or speeding up certain activities. As you might have realized from this post so far, column names matter! A good practice is to use verbs for columns representing active work. This way they are not confused as waiting columns. Even better, break down your active columns into Doing and Done sub-columns! Visually separating active work from waiting periods allows you to use the Flow Efficiency chart more effectively. Banish Blocked and On Hold columns Our final tip for this post is to say goodbye to Blocked or On Hold columns – or any other column with the same purpose. While these columns do help us see wait, they do not represent a stage of a lifecycle that happens in a predictable place. Rather, they are fleeting attributes of work residing in a particular stage of its lifecycle. We use columns to display the lifecycle stages of work. So, we need to use other visual queues to denote fleeting attributes like this. If you try to treat these attributes like a workflow stage by using columns, you are artificially picking a place in the workflow for it to reside. That wreaks all kinds of havoc! First, when you move an item into this kind of column, you can no longer see where in the workflow you experienced the wait. Did it get blocked in this stage or that one? Additionally, teams often use these pseudo-stages as a place to stash work so they can get around their WIP limits. This results in cycle times becoming longer and longer. Finally, when you are ready to put the item back into the real workflow, you have all of the data issues caused by backwards movement. A better practice is to visualize this kind of wait in the place where it is incurred. Yes, that may make it more painful but… that’s kind of the point. It can be the forcing function that causes you to face the problems instead of hiding them in forgotten columns. Add columns representing handoffs Handoffs are expected parts of the workflow and, when they come back from the handoff, they can move directly to next column on the board. In this way they are different than blocked or on hold columns and it is a very good practice to represent them using columns. The Key Takeaway In the end, there are no board police to decide what is right and wrong. There is no external governing body to keep you from making certain decisions for your board. Instead, it is up to you to understand the consequences of the decisions that you make and how they impact your ability to meet your goals. Take a moment to consider your board and the points in this blog post and determine if you can better enable flow!

Almost all teams occasionally move a card backwards on their Kanban boards for one reason or another. Moving cards backwards isn’t always a bad thing but, backwards movement can have unintended consequences when you’re calculating flow metrics. What happens to the data when cards move backwards? Many people assume that all tools measure the Cycle Time for a workflow stage by adding up all the cumulative time an item spent there. Tools like ActionableAgile that focus on metrics for flow optimization do not! How work moves through the process impacts how we capture Cycle Time for the process and any state within. So, what do we do? Well, the answer is best seen in the Source Data chart. It is the place where you can find all of the dates we’ve captured for an item’s travels through the workflow. ActionableAgile always starts by capturing the date when a work item first moves into a column (or a workflow status mapped to a workflow stage if you’re in Jira and not using a board.) In the image above, we can see that a work item with the ID of FLOW-10 began in To Do in November of 2018, was moved to In Progress in January of 2019, and moved through Release Ready into Deployed on the same day in July 2021. But, those captured dates can get removed when cards move backwards in that process. If FLOW-10 were to move backwards from Deployed into Release Ready for whatever reason, we remove the date stamp for Deployed. If the item were to move from Deployed through Release Ready all the way back to In Progress, we would remove the date stamp for both Deployed and Release Ready. Essentially, when you move a work item backwards, all of the time that it accumulated in the stage you’re moving it out of (and any stages that you’re moving it through) gets added to the time already spent in the destination workflow stage. So, in the image above, the data now shows that it has continuously been in In Progress since January 30, 2019. When it finally moves through those stages again, the date they revisit the stages will be captured in the Source Data chart. What does this mean for me and how I work? First, know that it is always ok to move a card backwards when it was a mistake to move it forward in the first place. Accidentally dragged the wrong work item to done? Just move it back to where it was accidentally moved from. Just make sure that you don’t move it back any farther or you’ll lose valuable data. For example, if you have a card that accidentally moved from In Progress to Deployed, move it back to In Progress. If you move that card all the way back to To Do then dates for all subsequent columns will be removed and it will look like it never left To Do. Once you understand how backwards movement affects your data, the inevitable question then becomes “Well, if I shouldn’t move cards backwards, what should I do instead?” The answer can be contextual but almost always lies in how you design and use your board. How you anticipate and plan for these activities as expected things rather than unexpected things can make a huge difference. We have a few key tips in a companion blog post on designing boards for flow. Take a look then contact us for any questions you might have!

Probabilistic forecasting via Monte Carlo Simulations are a key feature of two of our products, ActionableAgile Analytics and Portfolio Forecaster. These simulations can provide amazingly accurate forecasts with a couple of clicks of a button, but there are lots of considerations when it comes to the data you use to generate the forecasts. A customer recently asked us about one of these considerations and we thought it was worth sharing. How many sprints are required to get decent data for a Monte Carlo sim? Our tool warns you that your forecasts might be iffy if you have less than 10 data points (finished work items), regardless of the number of sprints you have. Daniel Vacanti, creator of ActionableAgile and well-known trainer and speaker on metrics, goes into a little more detail. He says “you can forecast once you have approximately 10 data points regardless of the number of sprints. However, the quality of the forecast you will get is rather dependent on how good of flow you have during the sprint. If all items finish on the last day, then you may need several sprints before you can make a good forecast. However, in that case your biggest problem isn’t the data, it is how you are running your process.” The underlying consideration The rule of thumb with Monte Carlo simulations is that the conditions that were present when you generated your past data are roughly similar to the conditions that will exist during the period you are attempting to forecast. The word “conditions” here can refer to many different factors: team capacity, the mix of work, amount of work-in-progress, etc. These will all impact your throughput and throughput is the data used to forecast via our Monte Carlo simulations. So, if you have 10 items and that 10 items roughly represents the mix of work you’ll be doing in the future, those 10 items may be sufficient. However, if you have more cyclical work items or other considerations, you might need a bigger data set that accounts for that variety. Improve forecasts by improving predictability The less predictable you are — meaning the bigger the variation in how long it takes you to deliver work and how many work items you deliver over time — the more data you might need to get a better forecast. If you aren’t happy with your forecasts, usually the answer lies in improving predictability by controlling the age of in progress items. The more you prevent unnecessary ageing, the better your predictability. Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.

At 55 Degrees, we think probabilistic forecasting is great. Heck, it is a key feature in our products ActionableAgile Analytics and Portfolio Forecaster. By basing your future outcomes on past outcomes, you can provide high accuracy with minimal effort. Assuming, of course, that current conditions are similar to your past conditions. Recently a customer had a great question stemming from his difficulties getting buy-in for using Monte Carlo simulations at his workplace. What happens if the forecasted likely outcomes from a Monte Carlo simulation fly in the face of the teams experience? How do you prove the model and get buy-in? Here’s our answer… One approach you might try is to talk up the pros of using a tool such as a Monte Carlo Simulation: Uses actual data from what you’ve accomplished before Can quickly run thousands of simulations to see how wide the range of possible outcomes really is Can give you a better understanding of which of those outcomes is really most likely Turns the focus away from whether or not a single outcome is right or wrong to determining how confident you need to be in any given forecast. That may make some headway. But, many hard-core proponents of effort estimates may need a bit more to decide that some simulation could be better at determining possible delivery dates than the experts themselves. What I try to remember is that what we’re really trying to achieve are better outcomes. Our success doesn’t (usually) live or die on which path people take to get the better outcomes. Add a pinch of science So, in this situation, why not let them take a more empirical approach and, potentially, prove it to themselves? Have people make a hypothesis of which they think will be better and why. Capture assumptions. Then, execute the experiment by utilizing both effort estimates and probabilistic forecasts. Finally, reflect and draw conclusions about which approach was better What do I mean by better? That’s a good question you should ask yourself when comparing a new option to your previous way of doing something. If either of the following conditions apply, I consider the new option to be “better:” More accurate (especially when no additional difficulty is added) Same accuracy but easier and/or less time-consuming A true scientist would tell you to repeat the experiment and see if the outcomes continually prove that conclusion. The worst case scenario is that a hypothesis proves to be wrong — yours or theirs. Either way, your forecasts win the contest because you’ve proven what is more accurate. Have you done this experiment? Share your outcomes in the comments below! Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.

A presentation at the Øredev developer conference in Malmö When I was a manager, I wanted to make a difference. A positive one. As a consultant, I work with managers who have the same goals. I’ve not yet come across anyone who wants to ruin everything (fortunately). When I started hearing the rhetoric about getting rid of the managers years ago, I was startled. Was I part of a huge problem that I didn’t even know existed? This question led me on a journey that had me studying the history of management and what people really thought of my past performance. I shared part of that learning in a talk at Øredev in Malmö, Sweden a couple of weeks ago. There is so much more to talk about on this subject that couldn’t fit in the talk. Please watch and let’s chat about your thoughts and experiences!

Sometimes you need to change your approach When I watch the news, read social media, or listen to arguments about how to do something, I am struck by how far we’ve gone into the land of right vs. wrong. Unfortunately, it doesn’t feel like we’re just passing through. Instead, it seems we’ve built permanent structures and are settling in for the long haul. An example: U.S. Politics To understand what I mean, you need to look no farther than the US political scene. In a two-party system, there is meant to be a constructive conflict between adversaries that results in largely beneficial outcomes for the citizens the two parties serve. Working through the merits of different viewpoints allows people to come to better solutions for tricky questions like “How much should the government spend on social services?” or “When should the federal government make laws vs deferring to state government?” Unfortunately for U.S. citizens, the adversaries have transformed into enemies. Instead of constructive conflict with productive results, we now have regular battles to see which party can come out on top. The topic seems to matter less and less as time goes on… the language is usually about winning instead of serving the citizens. Policy making in America is approaching all-out war, where victory is paramount, “compromise” is a dirty word, and virtually any issue or development can become a weapon for bludgeoning the other side. David A. Moss, Harvard business review, march 2012 issue Ironically, when you lose sight of the goal you are trying to achieve and focus on the act of winning at all costs, everyone ends up losing in the long run. The citizens lose first, then the politicians lose when the citizens are tired of losing. Battlefields exist at work too Unfortunately, this problem isn’t limited to politics. We see this behavior in organizations as well. It is common to see departments focus on their needs and desires at the cost of overall business outcomes. Consider the time you’ve spent in discussions about prioritization at work. When is the last time you came out feeling as if everyone could accurately and selflessly compare their request amongst all the rest? I am guessing the answer is “Not often” or “Never.” We see methodological ideologists bash ideas without any recognition of the struggle that led to its creation, what it might be trying to achieve. If you have no idea what I’m talking about, just search for posts about SAFe on any social media outlet. Most of the detractors have valid points at the core of their arguments, but I’d wager a bet there is a correlation between the level of vehemence in their arguments and their blindness to anything that might be good in SAFe. Methods aren’t alone in being a target. We do this with tools as well. Everyone has tools they love to hate so much that they can no longer recognize any value that it might actually provide. Jira seems to be the most popular target these days. Let’s face it, we do need to know the downsides of the things we love. Knowing the limitations of a thing helps us use that thing properly. But the inverse is true also. If you are going to be a detractor of something, understanding the value it might bring to specific contexts is important to recognize. If you are going to be a detractor, its best to be specific about the context you are speaking from. Is it just one specific context you have a problem with or are you convinced that this thing is bad in all contexts? In the long run, we don’t serve the public with tweetable, snarky quips. We serve them with a reasoned, minimally-biased look at whatever we are commenting on. What we need is a balance We can’t wait for someone else to act to begin to restore sanity. We all have a part to play. It starts with realizing that “not everything is a problem to be solved, some things are situations to be managed,” as Barry Johnson says in his book Polarity Management: Identifying and Managing Unsolvable Problems. This means that there is not always a right or wrong. Sometimes there is only a balance to be found between two opposing, yet valuable, forces. In Sweden, we call this balance Lagom and it is something that we have to discover in each specific context. When I first started thinking about this I began creating a Spectrum Thinking Worksheet to help people identify what balance looks like. It includes writing down the following info: The opposing forces (extremes) at play Why it is important to balance them The value that each brings The negative consequences of over-focusing on one extreme What it looks like when you get it just right One of the things I want to help people realize is that balance doesn’t mean settling for average, or splitting the difference. Finding lagom means finding the place of contentment or equilibrium. This balance should be sustainable. And, like with a fulcrum, where you find this balance is highly dependent on the makeup of the forces at the poles. It may be heavily weighted towards one side or another, depending on your context. If you explore the same spectrum in two different contexts you will likely find that lagom looks different in each. Keeping your balance Once you have explored the spectrum between, and including, two extremes, a Polarity Map helps us visualize how these forces are really interdependent pairs. How, if you over-focus on one area, hoping to achieve the positive effects, you can tumble out of balance into the negative consequences you were working really hard to avoid. I was really excited to find this concept of polarity mapping as it overlaps quite a lot with my work on finding Lagom. Like with our Spectrum Thinking Worksheet, polarity mapping asks you to identify: early warning signs that you are getting out of balance. action items that you can and will take if the early warning signs you anticipated start to appear. But, thinking through where Lagom is on a spectrum gives you some particular insights about balance that you might not get using polarity maps alone. Using one or both of these tools will help you switch your default from binary thinking to spectrum thinking and understand how to find a balance between two valid, yet opposing viewpoints. Getting Started Don’t wait for someone to make the first move. It is up to us to bring sanity back to our lives. Perhaps your move will inspire others or show them how to make a difference. Identify a situation in which you’re being too dogmatic or ideological, to the detriment of your well-being or that of those around you. Then, use the Spectrum Thinking Worksheet alongside a Polarity Map to a) articulate the value of the opposing perspective, b) explore the spectrum between and determine what balance looks like, and c) anticipate early warning signals of falling out of balance and action items you’d take to get back to lagom. I would love to hear from you if you are using the Spectrum Thinking Worksheet and/or Polarity Maps. How have you struggled? How have you benefitted? Please share with us via our contact form.