Podcast Ep. 50: How to Cope with Our Fear of Uncertainty to Deliver Better Outcomes

Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann explores how we, as humans, are intolerant of uncertainty to a large degree. We are actually inherently set up to dislike uncertainty in most situations.

So, how does uncertainty and our ability to be able to deal with it have anything to do with agility and our everyday work team? Well, Dan thinks it has everything to do with it. Uncertainty and our ability to cope with change affects how teams function, how people respond and even how the team plans projects in the first place.

In this episode, Dan jumps right into what uncertainty is (and why we, as humans, are rather intolerant of it), how we can better cope with uncertainty, how it relates to agility and how agility can be used to address uncertainty.

Listen on Google Play Music



Key Takeaways:

  • How do we respond to uncertainty?
    • As the uncertainty of an outcome approaches the 50% mark (i.e. there’s a 50% chance that an outcome could be either negative or positive), that is when our stress response is highest
    • If we already know the outcome (be it positive or negative), there will not be much of a stress response either wayit is with uncertainty that it is the highest
  • The five coping techniques as outlined in “5 Ways to Manage Your Fear of Uncertainty”:
    • 1. Commit to gradually facing uncertainty
    • 2. Connect to a bigger purpose
    • 3. Don’t underestimate your coping ability
    • 4. Bolster resilience by increasing self-care
    • 5. Appreciate that absolute certainty is impossible
  • How to address uncertainty with agility:
    • Shifting away from plan-driven software into a more agile approach can bring the fear that there is a lot more uncertainty in delivering softwarehowever, agility actually helps us face uncertainty by slicing capabilities and through establishing feedback loops
    • On the technical side of agility, uncertainty is also addressed through automated unit testing and test-driven development
    • Frequent code check-ins are also valuable in addressing uncertainty
    • In terms of connecting to a bigger purpose to address uncertainty, think of the Scrum Product Owner as a chief storyteller (their job is to articulate the purpose and help those on the team connect their contributions on a daily basis for the greater vision of the product overall)
    • “Don’t underestimate your coping ability.” When applied to agility it can be thought of as the ability to deal with things when they don’t go well
    • When people underestimate their ability to deal with software that may need changes down the line, they’ll overbuild softwareso it’s important to remember: YAGNI (You ain’t gonna need it!)
    • Most importantly, remember: “You don’t want to sacrifice the good enough for the perfect”you can always change the code down the line; it is not detrimental
    • Bolster resilience by increasing self-care with sleeping well, taking a nap at work (if you can), and taking a break when you’re feeling stressed
    • You can also bolster resiliency by growing your technical chops (through coding katas), looking for opportunities to engage with the broader community (through Code Camps or Meetups focused around your particular domain) and looking for opportunities to play at events like Global Game Jam (because social connections often bring you new opportunities and new ideas you can leverage on your teams as well)
    • It is important to remember that absolute certainty is impossible; there is no way of knowing our code will meet the needs of a user foreverin fact, it’s quite impossible to have the perfect solution that will work forever (so roll with the changes as they come in and simply embrace it)



Mentioned in this Episode


Dan Neumann’s Book Pick:

Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]

Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work, and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.

Dan Neumann: [00:16]  Welcome to this episode of the Agile Coaches’ Corner. I am Dan Neumann and thank you very much for joining and listening to this episode. Today’s episode is going to be focused on uncertainty. How’s it gonna go? Well, you’ll have to listen and find out. I came across an episode in fast company magazine and the title of it was Five Ways to Manage your Fear of Uncertainty. It was written by a practicing psychologist in the Washington DC area. The article was published under the section mindfulness at work and she goes through an explanation of how humans are really intolerant of uncertainty to a large degree. And then she gives some specific coping techniques and we’ll go through some of those. And what I thought was interesting where the correlations between the coping techniques she was discussing and agility and some opportunities within that. The author of the Five Ways to Manage your Fear of Uncertainty article makes the statement that humans are really set up to dislike uncertainty in most situations. One example of humans disliking uncertainty on a research project that was meant to measure that was a research study that was published by Archie de Berker and it has a very technical title called Computations of Uncertainty Mediate Acute Stress Responses in Humans and that’s a mouthful for sure, but the short of it is what they did was set up a very technical experiment that measured both subjective responses to uncertainty as well as some objective measures including the way your skin conducts electricity and the dilation of your pupil, which are some physiological responses to stress, and the authors of that study really found that as the uncertainty of an outcome approach. The 50% in meaning it could be there’s a 50% chance it could be a positive response or a 50% chance it could be a negative response. That was when the stress response was highest. And so what made their study unique was the degree to which they were able to measure that and it’s kind of cool how they set it up is they had participants doing a computer simulation where you would turn over a rock and there would either be a snake or not a snake in it and by itself that probably wouldn’t be terribly stressful except that then they delivered an electric shock to the participants when there was a snake under the rock, so there was a, there was definitely a, a downside to discovering a snake under a rock. So that was interesting to measure the physiological response and to correlate it to that threshold of 50% positive versus 50% negative outcome because if we know the response is going to be positive, their stress response isn’t that high. And if we know the response is going to be negative, the stress response isn’t that high.

Dan Neumann: [03:31]  So what do we do with this? That was kind of the article that was the focus of the fast company article. She, the author of the fast company article had five coping techniques that were one to commit to gradually facing uncertainty. Two was to connect to a bigger purpose. The third one was don’t underestimate your coping ability. The fourth one is to bolster resilience by increasing self care and the fifth one was to appreciate that absolute certainty is impossible.

Dan Neumann: [04:04]  At this point, it’s possible that you’re wondering what does the self care in fast company have to do with agility on my everyday work team? I mean we’re in business, we’re trying to deliver working software and honestly I think it has everything to do with how teams work and how people respond and even how we plan projects in the first place. So the first coping techniques to commit to gradually facing uncertainty. One of the big shifts away from plan driven software really into more agile approaches was that there is a lot of uncertainty in delivering software. We’re generally doing things that have never been done before. We’re using new technologies, we’re delivering new platforms, we’re working with new customers, and more and more the world in which we are trying to deliver the software that is ever changing more rapidly. And so agility really embraced this, taking what would traditionally be large requirements, big batches delivered over long periods of time and breaking those down into small slices of work. And it’s super helpful the small slices are not layered. For instance, we’re not delivering a slice of the database followed by a slice of the middle tier followed by a slice of the user interface. What we’re trying to do is generally deliver vertical slices that give some value to our users. Our last episode explored some of the principles behind the Agile Manifesto and the highest priority in that principle is to deliver working software to our customers. And so generally in most situations, working software is not a database unto itself or any of the other layers unto themselves, but it’s a slice of capability that goes completely through the stack. So agility can help us face uncertainty by slicing capabilities and then by establishing feedback loops.

Dan Neumann: [06:06]  In the extreme programming world, one of those feedback loops is your onsite customer. In Scrum we have a feedback loop easily provided by our Scrum Product Owner. We have individuals to whom the team can go and get the answers that they need when there is uncertainty. We take that level of the feedback and then we also can explore feedback on the technical side. Automated unit testing is invaluable for your software teams. What that does is that gives us the freedom to change the code and then observe whether the tests pass or fail. We often run into the challenge where there’s an intention to develop tests and to have unit tests automated, but then you know, push comes to shove and we want to build a new feature and we kind of forget the discipline that we wanted and that is where the benefit of doing a test driven development approach really comes in. For those not familiar with test driven development. It’s where we write the test first we write the code and then to make that test to pass and when the code becomes unwieldy or sub-optimal, then we refactor it so it has this concept of what’s called red green refactor, and that enforces the discipline of always having an automated test suite to validate your functionality.

Dan Neumann: [07:36]  So we have unit tests. In an uncertain world we also want to share that code with our colleagues. And so frequent code check-ins are super valuable to address uncertainty. We aren’t dealing with big batches of change then we’re dealing with small batches of change. We have tests that past, we have small batches, we have feedback loops from our customers, and all of those things allow us to gradually address the uncertainty of delivering working software. The second concept by the author of the article was to connect to a bigger purpose. Now we talked about the Scrum Product Owner just a few minutes ago and it’s easy to think of the Scrum Product Owner really just as the person responsible for the mechanics of the product backlog. Yes, they’re responsible for ordering the product backlog to optimize value delivery and that’s super important. What’s also important beyond the mechanics of that though, is to really think of the Product Owner as a chief storyteller. Their job is to articulate the purpose and really help the people on the team connect their contributions on a daily basis to the greater purpose or the vision of the product overall because let’s face it, it can be kind of a slog when you’re in there and you’re writing code, you’re not getting feedback, you know your releases are infrequent and so we want to address all of those things with agility. We want to have smaller chunks, more frequent releases, and more frequent feedback and at the same time make sure that we’re not losing sight of that greater purpose. The third concept was to not underestimate our coping ability and in this case it was really the ability to deal with things when they don’t go well. One of the drivers for a lot of that big upfront design in a traditional software approach is a fear of things like what if I have to change the code in the future? What if we run into a scenario that is different than our assumptions? And that leads to really building out architectures that are often overbuilt the phrase gold played and can be used for those where we really take our development to the nth degree and the concept I like to bring forward to address that is the concept of Y A G N I or you ain’t gonna need it. A lot of those concerns that lead us to overbuilding our software never come to fruition. And what if they do, then we change the code. Often that change to the code is not detrimental to anybody’s existence. Now, if you are working on mission critical applications where literally human lives are at stake, your threshold for coping with uncertainty is going to be different than if you’re writing what would be considered a more traditional business application.

Dan Neumann: [10:49]  So just keep that in mind that your threshold for uncertainty is going to vary based on what you’re doing, but in a lot of cases you can have in the business application sense, you can have fallback strategies that involve maybe some human interaction or some manual steps or some delay in the response. And so you can handle the bulk of the issues automated with a minimum of the code. In the concept of coping, one of the phrases that came to mind is you don’t want to sacrifice the good enough for the perfect. And ironically as I was getting ready for this podcast, I was listening to the songs school’s out by Alice Cooper and one of the phrases in that was, we can’t think of a word that rhymes, and I thought that was pretty cool that you’ve got this kind of famous rock song of school’s out for summer and right in the middle of it is this lyric, which is basically saying, yeah, we, we couldn’t think of the word that rhymes and but they shipped the song, they did not sacrifice the good enough, which turned out to be a very excellent song in my opinion anyway, for a perfect song where they had every line that was rhyming and I just, I love that they just acknowledged the fact that they didn’t have a word that rhymed for that part of the song. So there’s a really good chance that shipping your software is a really good thing. Even if you have some opportunity perhaps in the future where you are going to have to cope with something that changes.

Dan Neumann: [12:26]  The fourth item in here is to bolster resilience by increasing self care and from a psychology perspective, they talk about things like sleeping well, exercising and social connections. As I thought through that for I’m a software perspective, we definitely have the sleep well part. Yeah. You know what, there is some research that says, Hey, taking a little nap at work is actually good for you. If you aren’t comfortable with actually taking a nap at work, you know, maybe just go out and take a break when things get to the point where you’re, you’re feeling stressed and the brain isn’t quite working the way you want it to, so yeah, definitely take the breaks. From an exercise standpoint, that’s another opportunity to grow your technical chops. There are what are called coding katas, which is a really intentional activity to practice a software development skill. There are some fairly well known coding katas and these are sometimes set up as follow the leader type of activities where you can do them as a group and you and your team can grow your skills together or there are coding exercises that you can do independently. So maybe look for those. It’s a technical version of exercise and also look for opportunities to engage with the broader community and exercise muscles differently like code camps or meetups that are focused on your particular domain. If you’re a Product Owner, there are meetup groups for Product Ownership there are meetup groups for agility or Scrum, there are meetup groups for technicians of various skill sets. And so look for those and also look for opportunities to play at things like global game jam, which is going to be coming up in January. So shortly after the new year, there are global game jams where it’s a weekend long event where you get together and make games for the weekend. And what I’ve found is a lot of times those games are technical in nature. There are video games and it’s a great opportunity to exercise and to build more social connections. Those social connections will often bring you new opportunities, new ideas that you can leverage on your teams as well. And the last one is to really appreciate that certainty is impossible. So there is no way of knowing that our code will meet the needs of a user forever without change. In fact, it’s quite certain that that is not going to happen. It’s impossible to have the perfect solution that works forever. So there’ll be rework, there’ll be changes every once in a while we’re going to have to hold our nose and ship it, but it would be impossible to come up with the perfect solution. So don’t sacrifice the good enough for the perfect and just roll with the changes when they come in. Try to do things in your team with the way you handle changes and make that change as easy as possible and really embrace it because that’s where you’re going to have your new learning and be able to respond to it. So I hope that’s helpful for you. Some ways to deal with uncertainty and tying it back to agility.

Dan Neumann: [15:49]  From a reading standpoint, I have in the past found Lego simulations of Scrum to be super valuable, yet certainly is much more enjoyable for participants than to sit through a death by PowerPoint. And that is one of the learning edges that I have right now. So reading the book, Lego for Scrum, is one of the items I’m consuming to build my repertoire of Lego-based Scrum activities. And then Lego Serious Play as well, which is a broader mindset, and is a broader technique for using Lego, for solving challenging problems or for exploring challenging problems. So yep. Dusting off the Lego skills right now, and that is what I’m learning and we’ll put links to the articles that I mentioned into the show notes that are available at agile.com/podcast and would also welcome feedback, what topics are you most interested in hearing about?

Outro: [16:50] Have a topic you want us to tackle. Send an email to podcast@agilethought.com or tweet it with a #AgileThoughtPodcast.

Stay Up-To-Date