Aimee Bechtle

I'm Aimee Bechtle. I'm with S&P Global.

The Agile Manifesto emphasizes working software. You might have working software, but you might not be getting the results and value that you need, and you may want to check your thinking. That is, if you are thinking.

Like design thinking. If you have high abandon rates on your site, you have frustrated users contacting support. Design thinking is an approach where you empathize with the user so that you can create a positive user experience.

This is design thinking based on use and empathy. Who does this? Typically, a UX designer. They use tools like personas, empathy interviews, journey map. I like the journey map more than I like an NPS score. You can see the before and after, after you've implemented changes as a result of this thinking.

You go out. You empathize with the user. You define the problem. You develop an innovative solution. You rapidly test that solution before you actually develop something or a prototype, and then you repeat the cycle.

Oh, yeah, this is hard.

Product thinking. If you are making things that nobody wants, and they're not being used, and you have really good ideas and intentions, and you're losing market share, you might want to check whether you're doing product thinking. And this is how you uncover why people are using a product.

Design thinking: fit for use. Product thinking: fit for purpose. These are product managers using tools like lean canvas, value prop canvases. Tim Cook, great product thinker: we're going to build tools that nobody even knew they wanted.

Oh, so this is supposed to say product thinking.

You develop your business model. You define the value proposition. You do hypothesis testing, and you test your thinking with your users or with your market. You capture the learnings, and you measure progress.

Lean thinking. You have a costly process. You're slow to deliver value. You have a lot of waste. This is how you would organize activities and tasks around a value stream and create value by eliminating those waste and delays.

Delivery leads, or product managers, or project managers are the ones that typically do this thinking. The value stream map, 5S, Kanban. Making Work Visible by Dominica DeGrandis has become a bible for me at work, and it really emphasizes that thinking.

How do you do this? You identify your value-creating activities. You map out your value stream. You eliminate those non-value-added, show them in a Yamazumi chart. You do a pull system of work, and you continuously improve, and you always believe that there's a better way.

Systems thinking, one of my favorite. You have unintended consequences from change. You have a lot of rework or unplanned work. You only see the trees and not the forest. You need to start examining the whole, rather than focusing on isolated problems or components. You need to look at your ecosystem.

Who's doing this? Engineers and architects mostly. They use context diagrams. A causal loop analysis is a great tool for this. They look at functional flow and system architecture and do sequence diagrams.

So this is how they do that. They define their concept. They define that scope and boundary. They look at that boundary within the ecosystem of all of the other systems that they might interact with. They look at the dependencies and interaction, and they evaluate that change.

My favorite: stinking thinking. These are where you are having a really hard time getting change and transformation. People won't take time to change behavior or upskill, and they have a million reasons to deny, defend, or deflect from the real problem and avoid taking accountability.

Who's doing this? Change avoiders. They are doing all-or-nothing thinking and black-and-white thinking, and they're doing the worst kind of thinking: they are shoulding on you. Don't let people should on you.

So you know this one. There's a trigger event. There's a failed prod deploy. Negative feeling gets activated. Defensive reasoning kicks in. "It wasn't me. It was the dev and test environment didn't match production." You start blaming, conflict arises, and we repeat.

How do you stop this? Critical thinking. If you continue to repeat these problems, and you have heroes that rescue you from incidents and make big mistakes, you have low morale, burnout, you need to look at whether you're doing the logical reasoning. You're checking your bias. You're checking confirmation bias, and you're doing that analysis on yourself.

Learners and leaders do this. This is a sign of a continuous learning organization. There's psychological safety, active listening. You are learning about learning. Double-loop learning.

So you recognize a problem. "Yeah, my deploys keep failing to prod." But why is it? Instead of blaming somebody else, you say, "Is it the test environment? Is there a configuration drift? Is it true why this happened?" You do root cause analysis. You explore solutions. You build a pipeline, and you do DevOps.

So conclusion: we are in a time where we have to just rapidly deploy and deliver technology changes, and we might be just tempted to go and take shortcuts and build things. Don't shortcut your thinking, and think before you tech.

Yeah!