Agreeing on simple things (for example, where and when to meet) can be anything but simple. There can be miscommunications, incomplete communications, desires can change along the way, or people can learn things that change their availability or ability to get together. How do you make sure that you stay on the same page, even as you (and the things around you) change?
If you search YouTube for videos on expectation setting, though, you’ll get lots of results that talk about one-way communication around making sure someone (often someone with less organizational power) knows what you want from them. Lots of these videos are great, but they are limited to helping you build your skills around clear, concise, meaningful, tangible communication. And sometimes, expectation setting is indeed one-way, like for example when a company explains its return policy before you purchase something, or lets you know that there’s a real person behind its chat rather than a bot.
More often, expectation setting requires dialogue, and can’t just be unilaterally set by one party. When two parties (or a group of people) establish or update their shared understanding of a problem, situation, or scenario, then confirm that shared understanding, expectations are set. But that doesn’t mean you’re done.
Expectations erode over time. People learn, situations change, and relationships change. Especially in a work context, we might be setting expectations with a role, and people can flow in and out of roles. It’s not uncommon that we won’t have all the information or context we need going into a discussion, or that the information has become stale since the last time the parties reviewed it. Sometimes, new people are at the table, and we can’t make assumptions about how much understanding they have (or whether they’ve been introduced to the problem at hand at all).
For example, it’s common to scope a services engagement with the decision maker and project champion (who signs the contract), but be handed off to more operational contacts for the day-to-day work. Sometimes these operations people will not have had the opportunity to be briefed by the decision maker, who may or may not have prioritized getting their buy-in. You’ll have to deal with this challenge during the first opportunity you get to engage in expectation setting with this group of people.
The dialogue around expectations is ongoing, and you can tell it’s happening when you hear things like:
“What we think we’re going to do next is [this]. Has anything changed since the last time we reviewed this?”
“What I’m hearing is… [this]. Is that your understanding too?”
“So what I think you just said is… [thing I think you just said]. Is that accurate?”
“Let me reflect that back to you, and you can assess how close I am.”
“So if we do [this], does everyone here agree that’s the next step?”
I’d rather be disappointed now than disappointed and overwhelmed later by having to pivot. It’s good to be agile and be able to pivot, but it’s bad to have to pivot over and over again. (You have to regain your balance after every pivot. Sometimes this rebalancing is quick, and other times it never quite happens. Pivoting always comes with a risk, just like not pivoting can be risky.)
Expectation setting is one of the most valuable skills you can develop, especially if you are working as part of an agile team. Not only can expectation setting help you become a badass at work, but it will also help you build better relationships with friends and family.
Don’t assume that the world is the same as it was last time. Set expectations early and often.
Agility can be great (even though for many neurodivergent people, it’s the opposite of great). But when teams go through the motions to be “Agile” they often end up overcomplicating the work, adding stress to interactions, and achieving less agility.
If your agile processes are “working”, then over the next iteration (typically 1-4 weeks):
⬜ You have a clearunderstanding, as a team, of the value you’re working to demonstrate. (Note that this is not a promise or a commitment, but a shared purpose, direction and intention.)
⬜ You have a clearunderstanding, as individuals, of the actions that will generate that value. You know what to work on (and think about) when you’re not in meetings or with clients.
⬜ You don’t feel alone – you have teammates to communicate with and collaborate with, and resources you can use, as you move forward to advance project objectives.
⬜ You are working at a comfortable, sustainable pace.
⬜ Your team is improving every week – you continually do things a little differently to help improve quality, productivity, collaboration, or other outcomes.
None of these things require meetings (or “ceremonies”) – just communication and inclusion. We should always be asking ourselves and our team members: what’s the easiest, smoothest, least intrusive way of building this shared understanding and maintaining it every day?
When teams work with agility:
⬜ Everyone understands the overall goal and the next increment of value to demonstrate.
⬜ Everyone has clear things to do to contribute to that value.
⬜ Each person (and the team as a whole) works at a sustainable pace.
⬜ Nobody feels alone. There’s a group of collaborators to share the work with.
⬜ The client or project champion has visibility into the work and is happy with progress.
⬜ There’s an opportunity to rest, reflect, and adjust every week or two.
⬜ It’s not ridiculously hard to adjust to changes in scope, tools, or personnel.
But I regularly see “agile” teams flailing… unhappy… in constant panic mode, with stress that just won’t end. They are very busy and always seem to be scrambling to show their client or project champion some kind of value… with the feeling that they have to defend their existence. They have a nagging sense of confusion and impostor syndrome may be creeping in. They can tell you exactly what tasks are on their JIRA boards, but they can’t tell you why those tickets exist or how their task is contributing to overall project value. They have lost sight of the forest (value) because they have planted so many trees (tickets).
For these teams, the Scrum process and Agile ceremonies may be adding layers of stress and bureaucracy rather than helping the team work sustainably to consistently drive value. They are “doing Agile ” but have actually made themselves less agile… less able to flow and adapt and respond to changes in scope, tools, or participants.
Agile methods first emerged in response to the slow, painful, unsatisfying, unhappy practice of software development. It was really depressing to spend months building software, only to have customers and users complain how bad it was when they got it (especially when you developed exactly what they specified). It felt isolating to have to figure out how to deliver a piece of the software without any input from other engineers, and it was distressing when others were blocking your work and you had to convince them to listen to you. The whole endeavor was inefficient, and people were often tense and stressed.
The realizations in red (in the 90s) led to the Agile Manifesto items (2001) in blue
We’re applying processes and tools without really examining why we need them
So let’s prioritize…
Individuals and interactions over processes and tools
Why this is part of the Agile Manifesto: Since the beginning of time, development teams tend to get hung up on the details of using tools (e.g. MS Project, JIRA, kanban boards) rather than why the tools are there in the first place: to make sure people are getting the information and context they need – on a regular, routine basis – to make continuous progress on the team’s overall deliverables.
What we should do in 2022: Focus on information sharing, context building, and working arrangements that help people get work done. This applies to interactions within the team as well as interactions with the client.
We’re doing a lot of work that doesn’t actually contribute to our goal
So let’s prioritize…
Working software[ie. tangible stuff that’s valuable]over comprehensive documentation
Why this is part of the Agile Manifesto: Software development in the 1990s was documentation-heavy. I even remember, in 2018, throwing away a few hundred pounds of paper (in about 20 4” binders) containing requirements and design documents for a really big software project that we did between 2002 and 2004. Often, development teams wouldn’t even produce software that matched the documentation because we’d learn about what was feasible and what was not as we were doing it. Everyone tended to deliver software that the business needed a year or two ago. We didn’t learn together and co-create the software.
What we should do in 2022: We provide value in the form of information, shared understanding, and working software (which may be in the form of quality controls) – that’s it. Anything we produce that doesn’t directly contribute to making these things happen shouldn’t be done.
We’re unable to deliver something we don’t know how to define or describe yet
So let’s prioritize…
Customer collaboration over contract negotiation
Why this is part of the Agile Manifesto: Because deciding what you’re on the hook to deliver at the beginning of a project – and exactly what the deliverables are going to look like – is dangerous. You and the customer rarely have enough understanding of the problem (or of each other) to get it right.
What we should do in 2022: Establish shared accountability. (Note: this is rare. How many times has a customer been on your team and just as accountable to the project champion for the end result as you are?) A workaround is to set expectations with the client that we are discovering the shared understanding together, and we will get as close to the desired deliverables as we can, given the fact that we are embarking on a process of learning together.
We’re unable to commit to a plan when we might learn that our plan isn’t feasible
So let’s prioritize…
Responding to change over following a plan
Why this is part of the Agile Manifesto: As you learn about what’s possible, what’s not possible, and what the client actually values… plans will change. Instead of establishing a timeline that won’t end up working out (and that will cause you a lot of stress when you start deviating from), just start with the understanding that your Gantt Chart and your intermediary milestones will probably not be achieved when you think they will – or maybe even at all.
What we should do in 2022: Always keep the final goal in mind, but revisit and adjust the plan as you learn more every week. Iterate!
I saw a bunch of threads this morning on Twitter about pair programming, one of the core practices of XP and agile cornerstone. The arguments were diametrically opposed, either: it’s great, and the overhead is necessary and leads to long-term value; versus it’s terrible, because I need to get in the zone and that requires alone time.
(I don’t really like pair programming either… to be honest, I don’t have the attention span for it. I can get into my own groove, but it’s painful to follow along with someone else for more than a few minutes.)
Let me offer up an alternative: cogramming.
Cogramming is like pair programming, but you’re just programming next to someone on a module or a task that’s related to what they’re doing. (In today’s WFH climate, that might mean opening up a Zoom or a Google Meet, turning your cameras off, muting, and working independently until you encounter an issue that you’d ordinarily deal with inside your own head.) When you reach a checkpoint, or when it’s time to sign off, you can do “mini code reviews” to make sure someone else’s eyeballs have been on your work… and caught any big things that you might not have been able to see.
Does it work? From experience, yes. And there’s a basis for it in the research too, through the literature on collaborative play and group dynamics in kids. (Here’s an article that describes some of that.)
Cogramming can help you realize the benefits of pair programming without the pain of actually pair programming. Plus, managers will love hearing that they’re not losing any apparent productivity by two people working on the same code at the same time. If you’re anti-pair, try this approach before you give up entirely.
Agile is everywhere. Sprints are everywhere. Freshly trained Scrum practitioners and established devotees in the guise of Scrum Masters beat the drum of backlog grooming sessions and planning poker and demos and retros.
They are very busy, and provide the blissful illusion of progress.
(Full disclosure: I am a Sprint Grinch, and my heart will not grow three sizes, or even one… on any day.)
Despite the mirage of progress, the people on the front lines doing the engineering work feel little relief from the ill logic and misplaced pressure of the pointy haired bosses. The managers aren’t getting the deliverables faster (like they convinced themselves they would). There are tons of charts and graphs that tell us how we’re doing (like burndowns) but now the CFO is using them to whip our horses just a little bit harder, trying to get them to go faster. They’re not going fast enough. (Spoiler: They will never go fast enough.)
And isn’t that what Agile is supposed to do… speed things up? NO!
Once upon a time, we used to build software like we built skyscrapers: plan every single task, put in on a Gantt chart, and make sure there are approval gates between every phase of work: elicit requirements, design the systems, write code, test it, deploy it, maintain it.
But a couple of big, bad things tended to happen over and over:
By the time we got to “test and deploy” we’d discover that the thing we built was not what the users and stakeholders actually needed. (“But it’s exactly what you asked for in the requirements,” we’d say, “and you approved it at multiple decision points.” “Sure,” they would say, “but we learned a lot in the meantime, and things are different now. You just built us what we thought we needed six months ago.”)
The software developers would build something that the operations team, responsible for standing it up and maintaining it, wouldn’t be able to support at the intended service levels. (“You can’t expect us to maintain this,” they’d say. “It’s fragile.”)
Agile practices emerged more than two decades ago when engineers said… hold it, there’s got to be a better way. If we work collaboratively with our users and stakeholders, learning together, figuring out how to realize value together… then we’ll produce something that real people are able to get value from much faster. We need control over our process, and we need you to be actively engaged, business people. We can eliminate all these handoffs, and replace them with shared accountability.
The two solutions were:
Agile: We said “let’s take a more collaborative approach to development, and get the users and stakeholders together with the engineers, so they can all learn and co-create together until they’ve produced the next nugget of value.”
DevOps: Instead of two groups siloed from each other, let’s automate the handoff and make it seamless, and give the developers tools that will alert them when they’ve got to fix more stuff. If tests automatically run before the code is merged into production, we’ll always know that we’re deploying stuff that runs. (I’m pretty sure everyone agreed this was a good idea.)
Agile is a great aspiration. But how often have you ever seen the users and stakeholders sharing space, sharing accountability, sharing the process of creating value? Not often. They still coordinate through user stories, and tickets, and handoffs, and PRs.
Agile speeds up value delivery, but not necessarily software delivery. Having daily stand-ups and burndown charts and JIRA tickets won’t make people code faster. But it will make managers think they should be coding faster, and that’s where the poison will settle in and grow.
Bottom line, my position statement is:
Any (minimalist) process is better than no process.
Agility is an essential goal, but Scrum and certified Agile practitioners are less likely to get you there.
Go back to first principles: plan an iteration, co-create value, see where it got you and reassess your ability to reach your goal, then adjust. Keep experimenting.
Would I ever use Scrum? Sure, under specific conditions:
There’s something we have to build, and we’ve never built it before.
The road ahead is unknown.
We have access to collaborators who can help us see what’s needed.
We agree to intentional checkpoints where we can see how far we got, and whether we can still get to the place we’d originally intended.
We iterate, and iterate, until we agree we’ve incrementally added enough total value nuggets to move to the next project.
There are no well-meaning-but-not-helpful engineering managers or business managers hovering over the development team with bated breath, waiting to beat us with burndowns. The dev team can manage itself.
Agility is a laudable – and essential – goal. But only in rare cases do I believe Agile and Scrum will get you there.
I read well over a hundred books a year, and review many for Quality Management Journaland Software Quality Professional. Today, I’d like to bring you my TOP 10 PICKS out of all the books I read in 2019. First, let me affirm that I loved all of these books — it was really difficult to rank them. The criteria I used were:
Is the topic related to quality or improvement? The book had to focus on making people, process, or technology better in some way. (So even though Greg Satell’s Cascades provided an amazing treatment of how to start movements, which is helpful for innovation, it wasn’t as closely related to the themes of quality and improvement I was targeting.)
Did the book have an impact on me? In particular, did it transform my thinking in some way?
Finally, how big is the audience that would be interested in this book? (Although some of my picks are amazing for niche audiences, they will be less amazing for people who are not part of that group; they were ranked lower.)
Did I read it in 2019? (Unfortunately, several amazing books I read at the end of 2018 like Siva Vaidhyanathan’s Antisocial Media.)
The biggest obstacle in agile transformation is getting teams to internalize the core values, and apply them as a matter of habit. This is why you see so many organizations do “fake agile” — do things like introduce daily stand-ups, declare themselves agile, and wonder why the success isn’t pouring in. Scott goes back to the first principles of the Agile Manifesto from 2001 to help leaders and teams become genuinely agile.
#9 – Risk-Based Thinking (Muschara)
Muschara, T. (2018). Risk-Based Thinking: Managing the Uncertainty of Human Error in Operations. Routledge/Taylor & Francis: Oxon and New York. 287 pages.
Risk-based thinking is one of the key tenets of ISO 9001:2015, which became the authoritative version in September 2018. Although clause 8.5.3 from ISO 9001:2008 indirectly mentioned risk, it was not a driver for identifying and executing preventive actions. The new emphasis on risk depends upon the organizational context (clause 4.1) and the needs and expectations of “interested parties” or stakeholders (clause 4.2).
Unfortunately, the ISO 9001 revision does not provide guidance for how to incorporate risk-based thinking into operations, which is where Muschara’s new book fills the gap. It’s detailed and complex, but practical (and includes immediately actionable elements) throughout. For anyone struggling with the new focus of ISO 9001:2015, this book will help you bring theory into practice.
#8 – The Successful Software Manager (Fung)
Fung, H. (2019). The Successful Software Manager. Packt Publishing, Birmingham UK, 433 pp.
There lots of books on the market that provide technical guidance to software engineers and quality assurance specialists, but little information to help them figure out how (and whether) to make the transition from developer to manager. Herman Fung’s new release fills this gap in a complete, methodical, and inspiring way. This book will benefit any developer or technical specialist who wants to know what software management entails and how they can adapt to this role effectively. It’s the book I wish I had 20 years ago.
#7 – New Power (Heimans & Timms)
Heiman, J. & Timms, H. (2018). New Power: How Power Works in Our Hyperconnected World – and How to Make it Work For You. Doubleday, New York, 325 pp.
As we change technology, the technology changes us. This book is an engaging treatise on how to navigate the power dynamics of our social media-infused world. It provides insight on how to use, and think in terms of, “platform culture”.
#6 – A Practical Guide to the Safety Profession (Maldonado)
Maldonado, J. (2019). A Practical Guide to the Safety Profession: The Relentless Pursuit (CRC Focus). CRC Press: Taylor & Francis, Boca Raton FL, 154 pp.
One of the best ways to learn about a role or responsibility is to hear stories from people who have previously served in those roles. With that in mind, if you’re looking for a way to help make safety management “real” — or to help new safety managers in your organization quickly and easily focus on the most important elements of the job — this book should be your go-to reference. In contrast with other books that focus on the interrelated concepts in quality, safety, and environmental management, this book gets the reader engaged by presenting one key story per chapter. Each story takes an honest, revealing look at safety. This book is short, sweet, and high-impact for those who need a quick introduction to the life of an occupational health and safety manager.
# 5 – Data Quality (Mahanti)
Mahanti, R. (2018). Data Quality: Dimensions, Measurement, Strategy, Management and Governance. ASQ Quality Press, Milwaukee WI, 526 pp.
I can now confidently say — if you need a book on data quality, you only need ONE book on data quality. Mahanti, who is one of the Associate Editors of Software Quality Professional, has done a masterful job compiling, organizing, and explaining all aspects of data quality. She takes a cross-industry perspective, producing a handbook that is applicable for solving quality challenges associated with any kind of data.
Throughout the book, examples and stories are emphasized. Explanations supplement most concepts and topics in a way that it is easy to relate your own challenges to the lessons within the book. In short, this is the best data quality book on the market, and will provide immediately actionable guidance for software engineers, development managers, senior leaders, and executives who want to improve their capabilities through data quality.
#4 – The Innovator’s Book (McKeown)
McKeown, M. (2020). The Innovator’s Book: Rules for Rebels, Mavericks and Innovators (Concise Advice). LID Publishing, 128 pp.
Want to inspire your teams to keep innovation at the front of their brains? If so, you need a coffee table book, and preferably one where the insights come from actual research. That’s what you’ve got with Max’s new book. (And yes, it’s “not published yet” — I got an early copy. Still meets my criteria for 2019 recommendations.)
#3 – The Seventh Level (Slavin)
Slavin, A. (2019). The Seventh Level: Transform Your Business Through Meaningful Engagement with Customer and Employees. Lioncrest Publishing, New York, 250 pp.
For starters, Amanda is a powerhouse who’s had some amazing marketing and branding successes early in her career. It makes sense, then, that she’s been able to encapsulate the lessons learned into this book that will help you achieve better customer engagement. How? By thinking about engagement in terms of different levels, from Disengagement to Literate Thinking. By helping your customers take smaller steps along this seven step path, you can make engagement a reality.
#2 – Principle Based Organizational Structure (Meyer)
Meyer, D. (2019). Principle-Based Organizational Structure: A Handbook to Help You Engineer Entrepreneurial Thinking and Teamwork into Organizations of Any Size. NDMA, 420 pp.
This is my odds-on impact favorite of the year. It takes all the best practices I’ve learned over the past two decades about designing an organization for laser focus on strategy execution — and packages them up into a step-by-step method for assessing and improving organizational design. This book can help you fix broken organizations… and most organizations are broken in some way.
#1 Story 10x (Margolis)
Margolis, M. (2019). Story 10x: Turn the Impossible Into the Inevitable. Storied, 208 pp.
You have great ideas, but nobody else can see what you see. Right?? Michael’s book will help you cut through the fog — build a story that connects with the right people at the right time. It’s not like those other “build a narrative” books — it’s like a concentrated power pellet, immediately actionable and compelling. This is my utility favorite of the year… and it changed the way I think about how I present my own ideas.
Hope you found this list enjoyable! And although it’s not on my Top 10 for obvious reasons, check out my Introductory Statistics and Data Science with R as well — I released the 3rd edition in 2019.
Over the past few years, Agile has gained popularity. This methodology emerged as a solution to manage projects with a number of unknown elements and to counter the typical waterfall method. Quality practitioners have observed the numerous similarities between this new framework and Lean. Some have speculated that Agile is simply the next generation’s version of Lean. These observations have posed the question: Is Agile the new Lean?
ASQ Influential Voices Roundtable for December 2019
The short answer to this question is: NO.
The longer answer is one I’m going to have to hold back some emotions to answer. Why? I have two reasons.
Reason #1: There is No Magic Bullet
First, many managers are on a quest for the silver bullet — a methodology or a tool that they can implement on Monday, and reap benefits no later than Friday. Neither lean nor agile can make this happen. But it’s not uncommon to see organizations try this approach. A workgroup will set up a Kanban board or start doing daily stand-up meetings, and then talk about how they’re “doing agile.” Now that agile is in place, these teams have no reason to go any further.
Reason #2: There is Nothing New Under the Sun
Neither approach is “new” and neither is going away. Lean principles have been around since Toyota pioneered its production system in the 1960s and 1970s. The methods prioritized value and flow, with attention to reducing all types of waste everywhere in the organization. Agile emerged in the 1990s for software development, as a response to waterfall methods that couldn’t respond effectively to changes in customer requirements.
Agile modeling uses some lean principles: for example, why spend hours documenting flow charts in Visio, when you can just write one on a whiteboard, take a photo, and paste it into your documentation? Agile doesn’t have to be perfectly lean, though. It’s acceptable to introduce elements that might seem like waste into processes, as long as you maintain your ability to quickly respond to new information and changes required by customers. (For example, maybe you need to touch base with your customers several times a week. This extra time and effort is OK in agile if it helps you achieve your customer-facing goals.)
Both lean and agile are practices. They
require discipline, time, and monitoring. Teams must continually hone their
practice, and learn about each other as they learn together. There are no magic
bullets.
Information plays a key role. Effective flow of information from strategy to action is important for lean because confusion (or incomplete communication) are forms of waste. Agile also emphasizes high-value information flows, but for slightly different purposes — that include promoting:
Rapid understanding
Rapid response
Rapid, targeted, and effective action
The difference is easier to understand if you watch a couple cat videos.
This cat is continuously scanning for information about its environment. It’s young and in shape, and it navigates its environment like a pro, whizzing from floor to ceiling. If it’s about to fall off something? No problem! This cat is A G I L E and can quickly adjust. It can easily achieve its goal of scaling any of the cat towers in this video. Agile is also about trying new things to quickly assess whether they will work. You’ll see this cat attempt to climb the wall with an open mind, and upon learning the ineffectiveness of the approach, abandoning that experiment.
This cat is using as LITTLE energy as possible to achieve its goal of hydration. Although this cat might be considered lazy, it is actually very intelligent, dynamically figuring out how to remove non-value-adding activity from its process at every moment. This cat is working smarter, not harder. This cat is L E A N.
Hope this has been helpful. Business posts definitely need more cat videos.
One of the heuristics we use at Intelex to guide decision making is former US President Truman’s advice that “imperfect action is better than perfect inaction.” What it means is — don’t wait too long to take action, because you don’t want to miss opportunities. Good advice, right?
When I share this with colleagues, I often hear a response like: “that’s dangerous!” To which my answer is “well sure, sometimes, but it can be really valuable depending on how you apply it!” The trick is: knowing how and when.
Here’s how it can be dangerous. For example, statistical process control (SPC) exists to keep us from tampering with processes — from taking imperfect action based on random variation, which will not only get us nowhere, but can exacerbate the problem we were trying to solve. The secret is to apply Truman’s heuristic based on an understanding of exactly how imperfect is OK with your organization, based on your risk appetite. And this is where loss functions can help.
Along the way, we’ll demonstrate how to do a few important things related to plotting with the ggplot package in R, gradually adding in new elements to the plot so you can see how it’s layered, including:
Plot a function based on its equation
Add text annotations to specific locations on a ggplot
Draw horizontal and vertical lines on a ggplot
Draw arrows on a ggplot
Add extra dots to a ggplot
Eliminate axis text and axis tick marks
What is a Loss Function?
A loss function quantifies how unhappy you’ll be based on the accuracy or effectiveness of a prediction or decision. In the simplest case, you control one variable (x) which leads to some cost or loss (y). For the case we’ll examine in this post, the variables are:
How much time and effort you put in to scoping and characterizing the problem (x); we assume that time+effort invested leads to real understanding
How much it will cost you (y); can be expressed in terms of direct costs (e.g. capex + opex) as well as opportunity costs or intangible costs (e.g. damage to reputation)
Here is an example of what this might look like, if you have a situation where overestimating (putting in too much x) OR underestimating (putting in too little x) are both equally bad. In this case, x=10 is the best (least costly) decision or prediction:
plot of a typical squared loss function
# describe the equation we want to plot
parabola <- function(x) ((x-10)^2)+10
# initialize ggplot with a dummy dataset
library(ggplot)
p <- ggplot(data = data.frame(x=0), mapping = aes(x=x))
p + stat_function(fun=parabola) + xlim(-2,23) + ylim(-2,100) +
xlab("x = the variable you can control") +
ylab("y = cost of loss ($$)")
In regression (and other techniques where you’re trying to build a model to predict a quantitative dependent variable), mean square error is a squared loss function that helps you quantify error. It captures two facts: the farther away you are from the correct answer the worse the error is — and both overestimating and underestimating is bad (which is why you square the values). Across this and related techniques, the loss function captures these characteristics:
Not all loss functions have that general shape. For classification, for example, the 0-1 loss function tells the story that if you get a classification wrong (x < 0) you incur all the penalty or loss (y=1), whereas if you get it right (x > 0) there is no penalty or loss (y=0):
# set up data frame of red points
d.step <- data.frame(x=c(-3,0,0,3), y=c(1,1,0,0))
# note that the loss function really extends to x=-Inf and x=+Inf
ggplot(d.step) + geom_step(mapping=aes(x=x, y=y), direction="hv") +
geom_point(mapping=aes(x=x, y=y), color="red") +
xlab("y* f(x)") + ylab("Loss (Cost)") +
ggtitle("0-1 Loss Function for Classification")
Use the Loss Function to Make Strategic Decisions
So let’s get back to Truman’s advice. Ideally, we want to choose the x (the amount of time and effort to invest into project planning) that results in the lowest possible cost or loss. That’s the green point at the nadir of the parabola:
And time+effort grows as we move along the x-axis (we might spend minutes on a problem at the left of the plot, or weeks to years by the time we get to the right hand side):
What this means is — if we don’t plan, or we plan just a little bit, we incur high costs. We might make the wrong decision! Or miss critical opportunities! But if we plan too much — we’re going to spend too much time, money, and/or effort compared to the benefit of the solution we provide.
The trick is to FIND THAT CRITICAL LEVEL OF TIME and EFFORT invested to gain information and understanding about your problem… and then if you’re going to err, make sure you err towards the left — if you’re going to make a mistake, make the mistake that costs less and takes less time to make:
The moral of the story is… imperfect action can be expensive, but perfect action is ALWAYS expensive. Spend less to make mistakes and learn from them, if you can! This is one of the value drivers for agile methodologies… agile practices can help improve communication and coordination so that the loss function is minimized.
## FULL CODE FOR THE COMPLETELY ANNOTATED CHART ##
# If you change the equation for the parabola, annotations may shift and be in the wrong place.
parabola <- function(x) ((x-10)^2)+10
my.title <- expression(paste("Imperfect Action Can Be Expensive. But Perfect Action is ", italic("Always"), " Expensive."))
arrow.x <- c(10, 10, 10, 10)
arrow.y <- c(35, 50, 65, 80)
arrow.x.end <- c(6, 6, 6, 6)
arrow.y.end <- arrow.y
d <- data.frame(arrow.x, arrow.y, arrow.x.end, arrow.y.end)
p + stat_function(fun=parabola) + xlim(-2,23) + ylim(-2,100) +
xlab("Time Spent and Information Gained (e.g. person-weeks)") + ylab("$$ COST $$") +
annotate(geom="text", x=10, y=5, label="Some Effort, Lowest Cost!!", color="darkgreen") +
geom_point(aes(x=10, y=10), colour="darkgreen") +
annotate(geom="text", x=0, y=100, label="$$$$$", color="green") +
annotate(geom="text", x=0, y=75, label="$$$$", color="green") +
annotate(geom="text", x=0, y=50, label="$$$", color="green") +
annotate(geom="text", x=0, y=25, label="$$", color="green") +
annotate(geom="text", x=0, y=0, label="$ 0", color="green") +
annotate(geom="text", x=2, y=0, label="minutes\nof effort", size=3) +
annotate(geom="text", x=20, y=0, label="months\nof effort", size=3) +
annotate(geom="text",x=3, y=85, label="Little (or no) Planning\nHIGH COST", color="red") +
annotate(geom="text", x=18, y=85, label="Paralysis by Planning\nHIGH COST", color="red") +
geom_vline(xintercept=0, linetype="dotted") +
geom_hline(yintercept=0, linetype="dotted") +
geom_vline(xintercept=10) +
geom_segment(data=d, mapping=aes(x=arrow.x, y=arrow.y, xend=arrow.x.end, yend=arrow.y.end),
arrow=arrow(), color="blue", size=2) +
annotate(geom="text", x=8, y=95, size=2.3, color="blue",
label="we prefer to be\non this side of the\nloss function") +
ggtitle(my.title) +
theme(axis.text.x=element_blank(), axis.ticks.x=element_blank(),
axis.text.y=element_blank(), axis.ticks.y=element_blank())
Now sometimes you need to make this investment! (Think nuclear power plants, or constructing aircraft carriers or submarines.) Don’t get caught up in getting your planning investment perfectly optimized — but do be aware of the trade-offs, and go into the decision deliberately, based on the risk level (and regulatory nature) of your industry, and your company’s risk appetite.
