The Ultimate Metric – Identifying the Right Problems to Solve

Identifying the biggest pain points in your team can make all the difference in your organization. Janelle Klein, author of “Idea Flow,” discusses how to measure friction to connect managers and engineers using what she calls “the ultimate metric”: the frequency and duration of WTFs. Klein speaks about the importance of understanding and predictability to create alignment, taking into consideration the human factors in software development. “The hard part really isn’t solving the problems,” she reminds, “it’s identifying the right problems to solve.” This enables managers and engineers to translate the friction experienced during development into explicit risk models for more effective decision-making.

Accenture | SolutionsIQ’s Stas Zvinyatskovsky hosts at Deliver Agile Conference, Nashville


Read the full transcript

STAS ZVINYATSKOVSKY: Welcome to another edition of Agile Amped. I am your host, Stas Zvinyatskovsky and we are podcasting today from Deliver:Agile conference in Nashville. Today, my host is Janelle Klein. Welcome, Janelle.

Janelle is the author of Idea Flow, a data-driven approach to measuring the friction in developer experience and making improvement decisions with science rather than gut feel. After a 17-year career as a developer, consultant and a CTO, she is now a full-time entrepreneur building the meta tooling platform of her dreams.

Janelle is a former singer/songwriter and maybe we’ll get into talking about that and how that relates to software development. But, let’s just start with your talk today. The talk was titled The Ultimate Metric.

JANELLE KLEIN: That’s right. The Ultimate Metric.

STAS ZVINYATSKOVSKY: You kind of blew up Twitter after that.

JANELLE KLEIN: I did blow up Twitter! Just a bit.

STAS ZVINYATSKOVSKY: That is the ultimate metric I take it. The retweets and likes.

JANELLE KLEIN: It’s a good metric.

STAS ZVINYATSKOVSKY: All right. So, what is the ultimate metric?

JANELLE KLEIN: The ultimate metric is measuring the frequency and duration of WTFs.

STAS ZVINYATSKOVSKY: That’s a great metric. One of my favorite. So, I attended your talk and it was very interesting. What was your talk about?

JANELLE KLEIN: We have this huge disconnect in our industry between the management world and the engineering world, where we drive our projects into the ground over and over again. There’s a lot of reasons why that happens, but after this happened to me on a few projects I was working on especially things that I’d become pretty emotionally attached to, I was working on a project. Had my whole new team that I picked out and hired myself. It’s easy to get attached to the things that we’re working on but just having your project just stomped on and driven into the ground by ridiculous decisions that make no sense but that are ultimately caused by a communication disconnect. People not fundamentally understanding each other and communicating in ways where the message kind of gets lost in translation.

And then you’ve got these dynamics where management has control but no visibility. And engineers have visibility but no control. And so, we have this idea of Agile that we’re supposed to be really good at steering, but what ends up happening we end up all this buildup of pain and problems and inability to communicate what’s going on. We try and talk about these things in terms of technical debt but the message kind of gets lost and then we drive our projects into the ground and start over.

So, after this happened to me a few times on projects, I set out to figure out well how do we actually measure the pain and friction in software development and come up with an explicit way to measure these very real symptoms that are going on that are invisible and come up with a way to communicate these things and get on the same page about what are the problems that we ought to be fixing and get the management world and engineering world all pulling in the same direction.

So, my talk was about a paradigm of idea flow which is what my book is about. If you think about the flow of ideas between developers and the software. For example, I have an idea in my head and I’m trying to get that idea into the software. I want to mold the code like clay to represent the idea in my mind. If there’s an idea represented in the software I have to read the code to get that idea into my mind. You’ve got these flow of ideas between people in the systems and between different people and as opposed to trying to measure problems inside the code itself, we want to measure friction in these communication wires.

The reason I measured WTFs if you think about the process of communicating an idea to the software, if I’ve got an idea in my head I’ve got some intention of something I’m trying to change in the software to make those things in sync. And then when something unexpected happens, I run a test and the test blows up I’ve got some kind of unexpected output. At that point my understanding is out of sync.

How long does it take me from that moment of unexpected observation, that moment of WTF to the time I’m able to troubleshoot the problem and get those things resolved. So, if we think about this deviation as like a time to recover metric, a time to recover our understanding that what you see happening as the symptoms as we lose our ability to control the software, is these troubleshooting times start going out of whack.

And there’s some really interesting dynamics you see going on now with we’re still trying to measure our problems inside the code like measuring cyclomatic complexity. Trying to measure our technical debt or whatever. But what you see happening now is we’re shifting into this mode where 90% of our software is built from third party parts. We don’t build things from scratch anymore. We’ve got one line of magic code that doesn’t really have particularly high cyclomatic complexity, yet it’s easy to spend hours and hours and hours troubleshooting problems in that one line of magic code, right?

So, a lot of the pain that we experience is invisible. It’s not inside our code at all. Has to do with this friction when we’re interacting with the code and trying to troubleshoot things. And as opposed to trying to measure the causes directly, this method is focusing on measuring the symptoms you’re experiencing and the one thing that I learned in my career from all this is the hard part isn’t solving the problems, it’s really identifying the right problems to solve. If we can get really good at spending a little more time identifying the right problems, we can actually accelerate on our team.

So, continuous acceleration you can think is the art of identifying the right problem to solve. The art of leverage.

STAS ZVINYATSKOVSKY: Absolutely. It’s faster than speed. That’s great. How do you physically measure friction?

JANELLE KLEIN: How do I physically measure friction? So, the paper/pencil method that I went over in a session is you’re working on coding something. Write a little code and then you get to this process of working out the kinks. You run a test and something unexpected happens. WTF. So, jot down what time it is and you’re essentially starting a timer. Now we’re kind of in troubleshooting mode and then you work on troubleshooting the problem and then once you figure it out, you track the time of your yay of figuring it out. And then during the task basically just keeping notes and then make any notes that have to do with what turned out to be the cause of the problem. But, basically I’m just tracking the duration from WTF to yay.

STAS ZVINYATSKOVSKY: Yeah. I think that’s a great way to measure it. Is there an easy tool that you can install into your in ID or as part of your continuous delivery pipeline that allows you to measure that?

JANELLE KLEIN: This is kind of a mixed answer, but the tools that are kind of open source that I originally did research effort with with my book, they’re out there. They’re free. They’re open source. But, what I found in practice was that measuring data this way was doable for a short amount of time. But, trying to do this on any sort of sustainable basis was just too much effort.

And, I’ve had models for being able to aggregate this data and do really cool things with it for a long time, but trying to get over that barrier of actually turning this into a daily practice thing was really hard. And so, I mentioned, or you mentioned I guess when you were reading my bio, the whole entrepreneur thing, right? So, I spent a couple of years basically figuring out how do we take this idea strategy of measurement but then make it easy and a pleasure to use for engineers to come up with a strategy for making, gathering this data and learning from this data about the team and making the team go faster and not about managers being able to spy on people.

The metric tools and stuff that are often out there are often … sold to management specifically for that purpose. “You don’t trust your engineers? Here’s the strategy to spy on them.” This isn’t about that. It’s really about coming into alignment and being able to learn and identify where the things are going wrong so you can figure out how to do better, right? Coming together to figure out how to do better. As long as we’re in this mode where we’re trying to measure performance out of this, I think we’re fundamentally missing the point. A lot of the tool design stuff that we did was specifically geared toward making the tools really cool and fun to use.

The new stuff will be out … will start, should say, we’re about a couple of months now from our first MVP. Our first MVP we’re just doing with five customers though, so requires some squirrel work to set it up still for a team. So it won’t be online platform quite yet. And then after that we’ll be working our way into online platform mode but trying not to spread myself too thin too fast. And then bootstrapping this myself because I don’t really want to have anyone else telling me what to do either.

STAS ZVINYATSKOVSKY: Well, I’m looking forward to seeing that in action when it comes out. Once you capture the data, what do you do with it?

JANELLE KLEIN: A couple things. One is just as a team being able to identify the biggest cause of friction across your team so you can focus your improvement efforts on solving the highest leverage improvement opportunity, right? As I mentioned the hard part isn’t solving the problems, it’s identifying the right problem to solve. It’s so easy to spend tons of time working on improvement efforts that don’t really make much difference. But, if you can identify where the biggest pain points are on your team and focus on those things, makes all the difference in the world.

STAS ZVINYATSKOVSKY: Makes sense. One thing I heard you say was that the metaphor of technical debt is wrong. Did I get it right?

JANELLE KLEIN: I wouldn’t say it’s wrong exactly. I think the message is getting lost. I had this really interesting experience where at my old company I worked my way up to CTO and then found myself in all of these business mentorship MBA kinds of things as I got involved in this world. I was at this MBA class and talking to all these business folks and I was explaining this metaphor of technical debt and all these problems that we had. The response when I explained technical debt was, “Well, that doesn’t sound so bad.”

I’m like, well, don’t you want to know the interest rate, right? I learned something very important that day about how business people think about decomposing kind of a business problem. In the business world we’ve got a balance sheet where we’ve got revenue minus cost equals profit. We start with something like, okay, I want to improve profit by 10% and then we work backwards. So, working backwards we can only turn a few knobs. We can increase sales. We can reduce the cost. We can try and figure out how we’re going to improve profit by 10%.

And essentially what you’re doing is coming up with an investment strategy which boils down to I’ve got a set of buckets where I can put money and I divide the money I’ve got in the buckets. I’m making an allocation decision as managing this business. What I discovered was loans are looked at as a predictable financial tool. What makes investment decisions harder isn’t higher costs, it’s lower predictability.

If I know that I’ve got a steadily increasing loan over time, that this is going to operate like a loan, then I can go, okay, well, we’ll just increase the price to compensate for this. Or, we’ll just add more resources to compensate for this. We’re giving people these metaphors and since they don’t really understand the underlying system, they reason about the problem in terms of the metaphors we give them and these abstractions that we give them. The core problem with the loss of predictability, the loss of understanding, is not captured in the metaphor and so they don’t see it.

So, you see a lot of decisions getting made that don’t actually make sense but they don’t see it makes sense because the metaphor doesn’t make it not make sense. For example, your project is going off the rails and everyone’s super busy and things are all chaotic and falling apart and management’s like, iron triangle, right? We’ve got an increase in costs we’ll just add more resources that’ll fix the problem.

And so, you’ve got new people on the project then that don’t understand the software and then they’re breaking things and then the software’s all falling apart and then your people that do know the software it becomes a full-time job just to keep the project on the rails because these new people are screwing everything up. It just exacerbate all your problems yet from a management lens if all you have is this technical debt lens and you’re thinking about the problems like a loan which is fundamental disconnect with the dynamics of what’s really going on.

Once we lose our ability to understand the software, once we lose our ability to understand the relationship between cause and effect when we’re troubleshooting these things, we lose our ability to deliver software. We lose our fundamental capability. Not only that we cause so much stress on the team. We drive the people off the project with stress.

STAS ZVINYATSKOVSKY: That is absolutely true. Do you have a better metaphor to suggest?

JANELLE KLEIN: What I do is I explain this loss of predictability with dynamics of risk. I explain quality risk in terms of normal risk dimensions of increasing the likelihood of unexpected behavior and the cost to recover when anything goes wrong. When those factors multiply, you lose your ability to predict and you lose your ability to narrow those things down.

It has a non-linear effect. The ultimate constraint is our human limitations. Once we lose our ability to understand as humans, you’re kind of not in a good place. And there’s not necessarily an easy way to get that back. It’s much easier to sustain understanding than it is to get it back. This is why I focus on measuring WTFs as the primary metric because it focuses specifically on measuring that loss of understanding.

All these things that we do, we write tests, we try and write modular code, we try and design good architecture, break down our work well. All of these things we do are to try and help us get control of our software and maintain control and understanding our software. Sometimes these things that we do they’re effective and other times they’re not. Once we started measuring data this way it’s fascinating how often you run into situations where we do a bunch of refactoring to make things better and end up creating more problems instead.

But, you don’t … if all you’re doing is going, “Okay, well let’s make the software more modular because modular is better. Let’s write lots and lots of tests because more tests is better.” If that’s as far as you’re thinking about all these things, it’s really easy to create a mountain of test automation that doesn’t help you identify and track down the bugs and troubleshoot the things that you need to troubleshoot.

It’s really easy to build a modular architecture where you’ve still got dynamics of interaction and things that make stuff more difficult to troubleshoot and having things closer in adjacency would actually make things easier. What makes things easy or hard to understand is there’s a tons of factors involved in that. If we try and measure the causes directly, we try and make the assumption that things like high cyclomatic complexity is bad. Period.

And we focus on fixing those kind of things and come up with these dogmatic rules for what is better. We often end up in the situation where we make lots of things better, but the things that … We can either make things worse sometimes or end up in dogmatic arguments with our team where we’re changing things and making decisions and, I don’t know, there’s just so many ways that we make assumptions in software about what is going to be better, what is going to work that are based on nothing but … almost like a religion.

By measuring the actual symptoms of what’s going on, what’s causing these WTFs, what’s making things hard to troubleshoot, you start with the symptoms. Look at the specific problems that are going wrong, and then identify the causes by starting from the symptoms. I think the fundamental problem in our industry is just making all these assumptions that the things that were valid years ago when we were writing code are still valid today. There’s just so many factors involved and human factors involved that … I think we need to take a more scientific approach to how we go about the discipline of software development. I think we’re kind of at a point in our industry where we really need to make that leap of having a concrete method for science.

STAS ZVINYATSKOVSKY: Makes a lot of sense. One of the methods that you talk about is shared language. What is shared language and how does it help?

JANELLE KLEIN: Shared language, if I think about two people trying to communicate with one another, we’re all kind of weirdos on islands in our own little world. We all have our own version of reality in our heads. If I want to communicate an idea between two people, those people need some kind of shared protocol. If I imagine each little person is their own little bounded context, a shared language is basically a shared protocol where I can have a meaning in my head that’s attached to a word and that is attached to the same meaning in your word because we have a contract for what that word means.

STAS ZVINYATSKOVSKY: I have a very strict API.

JANELLE KLEIN: Exactly. Eric Evans in Domain-Driven Design, there’s a lot of really good material out there regarding the discipline and practice of developing shared language. But, at one level it’s not necessarily all that complicated. It’s like, let’s put together a glossary and put it up on a wiki and then we’ll come up with words for these things and then when I say this, this is what it means and we’ll all agree that that’s what it means and start using discipline around the language we use.

There’s one aspect of it that’s that. But, the other thing that I think we need to get better at is not stopping at words alone but working on systems of metaphor that characterize the dynamics that we’re trying to share an understanding about. This is where we have this metaphor of technical debt that we can describe what technical debt is and what it means and put a glossary around that thing. But, the metaphor itself creates blind spots in our thinking such that certain dynamics of software we don’t see that we really need to see and understand and reason about when we’re making decisions.

I think, again, it’s like we need to take a more scientific approach to how we build models, how we characterize and represent these dynamics. I’m working now with Michael Feathers on putting together what we’re calling a discipline of forms. Basically, kind of the art of everyday science and breaking down words into structure and forces and use sort of a scientific modeling technique to introducing vocabulary and systems of metaphors using it. This is still really early new stuff. I’m actually giving a talk at Explore DDD in September specifically on anatomy of communication and doing a first cut of breaking these things down.

STAS ZVINYATSKOVSKY: Fascinating. And so, that Explore DDD that’s in Denver in September of this year?


STAS ZVINYATSKOVSKY: Excellent. One thing I noticed and I remember this is maybe 10, 15 years ago with my previous company, we were trying to normalize the language of testing. People fought tooth and nail over the language that they used. They perceived our attempt to normalize it as almost … I don’t know, they perceived … they got very … people got very defensive around trying to normalize language.

JANELLE KLEIN: Interesting.

STAS ZVINYATSKOVSKY: Have you seen that?

JANELLE KLEIN: If you take a word that someone else is using and try and change it to mean something else and say, “We’re going to make this the new meaning of the word and you need to change your meaning to our meaning.” I don’t think that works. I think this is where the idea of bounded context and coming up with like if we’re going to define a shared language we can say, “Okay, when we use these words in this context that these mean these things.”

But, that doesn’t mean you can’t have your own language and your own context, right? Or, sometimes we have a system of metaphor, a system of meaning that we need multiple lenses to look at a problem. Multiple kind of metaphors to look through in different ways of thinking. It’s not a one or the other. It’s both. And so, I feel like by being able to take a language and say, okay, this language is this bounded context and when … and you can sort of define that as a protocol of like, “Okay, right now in this conversation we’re going to use this language and set of meanings and terms and then everyone learns when they’re in that context to use that set of language and meaning and terms. When we’re in this other context we’re using this other language.”

I think as long as everyone knows what language you’re speaking, that’s the main factor that avoids confusion. I guess the thing I would say is if you can find out what are the reasons behind why people have tension? Is it because they have other meanings associated with that word so they feel like there’s some important meaning that’s getting lost? Turn it into a conversation. We’re all weirdos. We all see things in a different way and the beauty of working together as a team is taking all those different perspectives and being able to weave them together such that we can see things from a whole bunch of different angles with a whole bunch of different people.

But, in order to be able to communicate, we need some kind of shared protocol that everyone can agree on otherwise we get confused and that’s not good either.

STAS ZVINYATSKOVSKY: Makes a lot of sense. Thank you. I want to talk about your book. Idea Flow. It’s somewhat of a dramatic software tale isn’t it?

JANELLE KLEIN: I didn’t want it to read like a dissertation. Instead I wrote the book kind of like a novel more in the style of Phoenix Project. I was working on this project where we did all the right things. Had CI unit testing, design reviews, code reviews, all the things you were supposed to do and I was working on this really great team, one of the best teams I’d ever worked on. But, despite all these things, I watched my project hit a wall. We brought down production three times in a row. The project went off the rails. We didn’t ship again for another year when we were trying to figure out how to turn this project around and tried a lot of things that didn’t work.

The book is basically a story narrative of what we discovered was going off the rails, these bad decisions and how we came up with this data-driven technique that ultimately gave us the insights we needed to turn the project around. It wasn’t an easy effort. This is like three years it took us to get the project really back on track. But, we went from legacy project that was just sliding off the rails, couldn’t ship anymore, lost our ability to understand the system, to learning what the biggest problems were with the data-driven technique. Learned how to model the risk dynamics that were really going on. Coming up with strategies for solving those problems. Coming up with strategies for communicating this stuff to management.

And I walked through the story of turning our project around. How to make the case to management when you have this data. I’m going through the technique and the story basically at the same time. So, it reads like a novel but you learn a whole bunch of stuff at the same time.

STAS ZVINYATSKOVSKY: I love the stories. One of the little tidbits you mentioned to me was that you visualized pain.

JANELLE KLEIN: Yeah. That’s a big part of it is visualization is amazingly powerful. I started this technique of idea flow mapping and essentially visualizing the friction you experience during development and I basically have this timeline where is all relative time. You start a task at time 00 right, and then as time ticks forward I’m looking at how much time is going by. And then I’m capturing these WTF to yay transgressions in red.

So, you basically get a timeline that’s got these red bands on it and get a feel for how much friction you’re experiencing and for the different types of dynamics with different types of tasks. You start to see the effects of, hey, if I break down my work into small, little pieces then I get idea flow maps that look this. If I go, “eh, I don’t really feel like writing tests today,” and then I end up with a big haystack of changes and I’m troubleshooting all that stuff at the end, you get a idea flow map that looks a lot different.

You start to get a feel for these things. I started using this as a mentorship technique and mentoring my team based on kind of understanding the dynamics of friction and the problems that would come up and using the visualizations as a way to teach.

STAS ZVINYATSKOVSKY: Interesting. What’s interesting is that this pain it has physical manifestation.


STAS ZVINYATSKOVSKY: You go, you visit a lot of companies, you see it actually as you walk the halls. There are companies where people are smiling and they’re happy. And there are companies that are in pain, in constant pain.

JANELLE KLEIN: Yeah. Studying these feedback loops this way led me down this road of studying brains and I got really interested in cognitive research stuff. One of the things I spent a lot of time thinking about was the nature of human stress. If you imagine an environment, which shouldn’t be that hard, where you’ve got this high urgency environment, you’ve got a release going out the door. You’ve got a bug somewhere in the software, an error message on your screen that you don’t really understand, and you’re under the gun trying to figure out the relationship between cause and effect in some landmine of complexity of stuff. You’re confused. It takes a lot of brain power to do this and it’s physically stressful.

I’ve had experiences with the treadmill of working 60, 70-hour weeks and getting caught up in this mode of constant urgency and that stress builds up to the degree that I’ve seen people die on projects from the cognitive stress and overload. It really is physically taxing. It’s not okay to pretend that that stress isn’t real and doesn’t affect people.

The things is, is it doesn’t have to be that way. Software is this amazing craft. We can take ideas in our head, bring them to life. It’s really freaking cool! There’s all kinds of ways we can come together as people and collaborate and come up with cool things that we can build and make stuff for people and it’s like a lot of fun.

There’s no reason it needs to be this crazy stress grind. There’s no reason that having fun and making money can’t coexist. Software’s already fun. Software is already this joyful, cool thing. It’s super fun to be able to do together with others. I think all we need to do is just not screw it up. Come up with ways that we can make money that don’t drain all the fun away. It doesn’t need to be this crazy, abusive dynamic. It just doesn’t.

STAS ZVINYATSKOVSKY: It’s immoral too, I think, for a lot of leaders to put their teams through that.

JANELLE KLEIN: Well, I think it’s … Once you end up on that treadmill, it’s really difficult to get out of, so you just kind of get in survival mode. This is where I kind of learned in taking a step back that the fundamental problem is a communication disconnect.


JANELLE KLEIN: So, this is why I’m like, okay, people are people and they really don’t get it. Maybe as opposed to getting upset with people and angry with people for where they are, we can go, “Okay, how do we fix the communication problem? How do we get people on the same page and how do we create alternative ways to run things that work out better?”

I think it’s easy to be in a mode we’re like blaming people and angry about all the things that are broken, but what are we going to do different? If we erase the world, start over a new software, a new organizational technique. We’re going to build a learning organization, what does it look like? I think the other gap here is we lack templates for how to run things differently. We can rail against the machine all we want, but if we don’t have workable alternative templates to follow for doing things different, it’s not really going to change anything. It’s like complaining because stuff’s broken and not really providing solutions either and so nothing gets better.

It’s interesting too, I talk about this disconnect between management and engineering, and management having control but no visibility, and then I presented those slides to a bunch of management folks and they’re like, “Managers don’t have control either.” It’s like they look at the world almost the same kind of way of like, “The investors are the ones with the control and we’re stuck having to do what they say.” Managers are kind of like in the middle in that they don’t have control or visibility.

STAS ZVINYATSKOVSKY: That’s right. You talk to the CEO and CEO says it’s the board of directors.

JANELLE KLEIN: Yeah. Now that I’m in entrepreneur mode I’m like, got to bootstrap this myself because I don’t want anybody telling me what to do.

STAS ZVINYATSKOVSKY: Let’s talk about fun stuff how you got into software engineering. You were a singer/songwriter.

JANELLE KLEIN: Yeah. When I grew up, music was my whole entire life. I wrote music all through high school. I played guitar and sang and played flute and I played in the city orchestra and wrote jazz choir pieces and orchestral pieces. I was really into songwriting. When I went to college I went to school to be a professional songwriter. That was my dream. Wanted to be just like Jewel.

But, then I got into college and I started to realize what a career in music would actually be like. I was like, I don’t think I actually want to have to do this to make money. It’s like it took all the fun out of it for me when I had to think about how I’m going to do this to make a living. I was kind of distraught. Didn’t really know what I was going to do and then my boyfriend at the time he’s like, “Well, let’s take a class together, it’ll cheer you up.”

He’s looking through the class catalog he’s like, “Ooh, assembly programming, that looks like fun.” And so here I am in this assembly programming class and I know nothing about computers. My only experience with computers was playing Kings Quest with my family. And so I got in the class and I realized that programming computer was kind of programming my TI-85 in math class. I’ve got some basic instructions. I can do this. And then I started flipping through the textbook and then I found interrupts and I realized I can switch to graphics mode. I can make the PC speaker beep and I can make the computer make music.

I got so excited about all the things that I could do and I started writing the game Breakout completely in assembly with … I made … I switched the screen to graphics mode so I had 256 color mode in rainbow blocks and I had a little paddle that moved around with the mouse and the ball bounced around the screen and went, “Ping, ping, ping.” It was great.

I showed my teacher what I was working on and he’s like, “Why don’t you just keep going with that and you get an A.” Like, “All right, I like this class this is awesome.” But that’s when it hit me. I have to do something but I can create anything I can dream. Anything I can possibly take in my mind and translate into code I can bring to life. I realized software was like this ultimate creative medium. How amazing is it? Software magicians of the modern age, right?

STAS ZVINYATSKOVSKY: That’s awesome. I think that’s a great closing statement. Software people are the magicians of the modern age.


STAS ZVINYATSKOVSKY: So, Janelle, thank you so much for coming and talking to us.


STAS ZVINYATSKOVSKY: I appreciate your time. Thank you. Thanks again for listening to this edition of Agile Amped. If you learned something new, please tell a friend, a coworker or a client and subscribe to hear more inspiring conversations.