Mastering Work Intake: From Chaos to Predictable Delivery with Tom Cagley and Jeremy Willets

Navigate the twists and turns of Agile project management with us, Mark Metze, as we host the masterminds Tom Cagley and Jeremy Willets. Their expertise is distilled into a riveting conversation that promises to arm you with the strategies to turn the chaos of work intake into the rhythm of predictable delivery. Their insights are drawn from the pages of their book, "Mastering Work Intake: From Chaos to Predictable Delivery," and they unveil how unmanaged work entry points are the Achilles' heel of otherwise solid transformations. Discover why the human inclination to overcommit is a path to burnout and how setting clear boundaries can save your team from the dreaded 'death march' of workloads.

Transform your workflow clarity as Tom and Jeremy guide us through the maze of prioritization and sequencing. With their practical advice, learn how visualizing work not only demystifies the process but also paves the way for meaningful enhancements, regardless of department silos. They illuminate how to employ transparent prioritization techniques, like cost of delay, and to sequence work in a way that fosters stability and prevents the common pitfall of haphazard task management. The art of maintaining a productive cadence of work, free from the shadows of office politics, can be your reality by applying their shared wisdom.

Wrapping up our thought-provoking session, we confront the headaches that emerge when modernizing legacy systems. Listen as Tom and Jeremy dissect the perils of excessive work in progress and its impact on development teams' well-being. They underscore the importance of leadership's role in setting feasible goals and managing customer expectations during times of transition. Their conversation is a lighthouse guiding through the fog of work intake challenges, offering a beacon of strategies to keep your project's course true. Don't miss this chance to steer your Agile projects toward calmer waters with the guidance of two of the field’s most insightful navigators.

Connect with Tom on LinkedIn:
https://www.linkedin.com/in/tcagley/

Connect with Jeremy on LinkedIn:
https://www.linkedin.com/in/jeremywillets/

Read Tom and Jeremy's book "Mastering Work Intake: From Chaos to Predictable Delivery":
https://www.amazon.ca/Mastering-Work-Intake-Predictable-Delivery/dp/1604272007 (Amazon)

https://jrosspub.com/catalog/business-default-category/project-program-management/mastering-work-intake/ (J. Ross Publishing)

Join Tom and Jeremy's 5-week Cohort Course:
https://maven.com/jeremy-willets/masteringworkintake

Listen to the Software Process and Measurement Cast with Tom and Jeremy:
www.spamcast.net

If you visit the Southeastern US, eat at Piccadilly and don't let your eyes become larger than your stomach!
https://www.piccadilly.com/locations

Join the Alliance and support the show!

Transcript

Mark Metze: 0:06

Welcome to the Agile Within. I am your host, mark Metz. My mission for this podcast is to provide Agile insights into human values and behaviors through genuine connections. My guests and I will share real-life stories from our Agile journeys, triumphs, blunders and everything in between, as well as the lessons that we have learned. So get pumped, get rocking. The Agile Within starts now. Welcome back, everybody, for another edition of the Agile Within podcast. This is your host, mark Metz, and I have two guests today, so you're getting two for the price of one Today. I want to welcome Tom Cagley and Jeremy Willits. Tom and Jeremy are also podcasters and they have a podcast called Software Process and Measurement Cast. Tom and Jeremy, I'll let you introduce yourselves, tom. Why don't you go first?

Tom Cagley: 1:06

Okay, thank you. I'm Tom Cagley. I'm a podcaster, an author, an agile guide, been around the block a few times, have coded a little bit, tested a little bit, made a hash out of all sorts of systems over many years. So that's who I am and you know we're. Jeremy and I are in this together.

Jeremy Williets: 1:33

That we are. Tom Jeremy Willits probably been around the block one fewer time than Tom has been around the block, but I've been working in the Agile space for the better part of a decade or more doing scrum mastery kinds of things, agile Cochie kind of things. Got my start as a tech writer on a scrum team and fell in love with scrum. Fell in love with the manifesto and the principles and have been doing this kind of thing ever since.

Mark Metze: 1:54

So Tom and Jeremy have co-authored a book Mastering Work Intake from Chaos to Predictable Delivery. What was your inspiration for writing this book?

Tom Cagley: 2:04

Well, let me take the first crack at this. Very frankly, I think our inspiration and obviously we both had slightly different, but we both recognized that people whether it's Agile or any other attempt at doing sort of formal system development failed a ton of times and any sort of transformation tended to fail and a lot of that was because nobody kept in control of the backlog work, entry kind of thing, and it really really became apparent that that's why so much of this attempt at getting on things under control never works, because everybody just waved their hands and magically thought that would happen. When we did things like scrum or save or, you know, rub or any of the other frameworks that we've attempted over time, it just kept control of that boundary.

Jeremy Williets: 3:09

That was my rationale, and my rationale is kind of different. It really started when Tom pulled me aside in the early days of the pandemic. We were doing happy hour, friday calls, like so many people, drinking a couple adult beverages and trading stories, and you know, tom had this idea and this topic and he pitched it very much like he just described it to you here, mark, and I was immediately hooked. He asked me if I wanted to start to write a book on the topic and I jumped at the chance to work with Tom again. I jumped at the chance to dust off my keyboard and start putting together some content on this topic because I do think it's imperative. It's often overlooked. We spent probably the first, you know the first month writing this, but when we weren't just crafting paragraphs here and there, we started we were searching our catalogs.

Jeremy Williets: 3:53

Tom has a giant bookshelf behind him that I can mentally see right now. That's full of books, and he spent hours combing through different texts looking for topics that dealt with work intake, and we just couldn't find them. So we thought that this would serve a need that is out there in the marketplace.

Mark Metze: 4:07

You want to make a food analogy. Food is one of my favorite subjects, I'll have to say that Upfront. As a young child, I can remember my parents taking me to a place called Piccadilly's, and Piccadilly's was.

Tom Cagley: 4:19

Oh my.

Mark Metze: 4:21

Okay, so you know. I've looked in the South.

Mark Metze: 4:24

I know, piccadilly, yeah, so you would go through the line and you know they would have all the different foods prepared and it wasn't a buffet, but you would tell them what you want. Of course, when the desserts come, you have to get two or three desserts right. And then, from a very early age, we learned that our eyes are bigger than our stomachs, and I can remember my mother telling me that every time we took a trip to Piccadilly's to have lunch. So why is it, at least in the software realm where we're developing products, why do we have such a hard time saying no and letting our eyes be bigger than our stomachs?

Jeremy Williets: 5:02

Well, I'll take this one first time. I mean just kewing off of the example you gave us, mark. I think it's a human tendency to say yes to things. It's a human tendency to want more. So if you take that human tendency into the workplace, into either a software firm or some sort of product firm, and you want to be a good co-worker, you want to be viewed as a team player, and somebody comes to your desk and says, hey Tom, hey Mark, can you do this thing for me? It's important, it's got a customer tied to it, but it's everybody's favorite phrase, it's a top priority. Quote unquote. The natural human reaction is to jump at the chance to say yes, to do your colleague or compatriot or friend a favor, if you will, and help them out.

Tom Cagley: 5:48

I'll take the dark side of this. Jeremy had the light side of the Force. I'll take the dark side of the Force on this one and suggest that you have the Emperor's Death March.

Mark Metze: 5:58

Is that where he's going? There you go. The Star Wars, yeah.

Tom Cagley: 6:02

All of this stuff does lead to death marches. I'd like to suggest that in many organizations it is not safe to say no and that saying no is career limiting. My family gets together on Saturday nights to have a Zoom call. That started way back in the kovat days and we're still doing it, and I have a number of brothers and with their children in major consultancies and it was being pointed out during the call this week that if you're not working sixty to eighty hours a week as an entry level person and saying yes to everything and you ought to find different career.

Tom Cagley: 6:52

And and I? That's just an anathema to me, given that I know that those sorts of things end up with really horrible quality right, if you continue shoving stuff in. It doesn't end well for anyone. Cue the emperors death mark. But I do think it. You know. I think a lot of organizations. It's not safe, it is career limiting to say no, regardless of whether or not you. You say I'll do it later and just, or I'll put it on the backlog. People understand that that's code, for if I just stuff it on the backlog, it's either code that I'm gonna start it tomorrow or I'm never going to do it. You know we can. We can determine as to whether they're not.

Mark Metze: 7:36

Which of those two things that they'll guess that you mean by that and it's the never, then they're not gonna look well on you when someone tells you they're putting it on the backlog and you assume that's going to be sometime soon and not never, and you don't ask in the moment so will that be next week, next month? What's gonna happen next week or next month comes and you ask and question comes up of where's that item that you said you put on the backlog?

Tom Cagley: 8:05

I agree, I agree. Let's go back to your food analogy, or one of the food analogy. Wimpy and wimpy always walked around, said please, can I have a hamburger today and I'll give you a dollar tomorrow? Right, so he was postponing the fact that he would have to pay the money back. We I think a lot of times put that stuff on the backlog. We're not sure where we're gonna start it hopefully will prioritize it, find out that it's important or not important, but if it's not important, we hope people forget, so that we will never have to pay that dollar back in the future. Jeremy, what's, what's your experience with that?

Jeremy Williets: 8:57

I mean it's it's uncomfortable to tell a person no. I think that One of the one of the lessons that hopefully we try and convey in our book is it's not, it's teaching people the right way to say no. It's not just coming to the table and saying no. It's bringing data to the table, for example, to have a conversation with them about Whether it's priority or sequence or capacity it, but really to promote no being a rational conversation versus just in a gut instinct and a gut response.

Tom Cagley: 9:27

But it's a conversation that has to happen, even if you have to get to the point where you really have to have that. We're just not going to do this. It doesn't make sense, it's not our highest priority. If we do that, then we don't do this. All of those kind of conversations at some point you do have to say no office have been in this business for a few days. We know beyond a shadow. Without that, we've got to do lists or backlogs or project charters or some sort of requirements document. That's twice as big as what we can do in any period of time. Either try to find a way of doing it and pile up a whole ton of technical debt, or you have the conversation about what's my priority? Which ones do? We have to work on sequencing for such that you know it may not be as quite as high priority, but we have to do this so that we can get to that kind of a conversation. Those are hard and, jeremy's right, they're uncomfortable.

Mark Metze: 10:35

They're uncomfortable because we haven't created cultures to have those hard conversations got a hypothetical and you can't see me giving the air quotes because it's a hypothetical situation. This may or may not have happened to me in the past. So you're working at a company and the company has moved from the startup phase. They're finding success and they're starting to mature. They're starting to grow and you're starting to scale, and the things that made the startup successful now are starting to show, as you're starting to scale larger, are starting to rear their heads.

Mark Metze: 11:15

When you started as a startup, you had a CEO or a leader who was very good at casting a vision of what the company to do to stay afloat, because when you're a startup, you've got to make a profit. If you don't, you're not going to have a job, companies not going to exist. But now that the company is starting to get larger and more people are starting to get involved, the CEO steps in and says hey, hey, hey, I've got this great idea. I want you to deliver this by the end of the year, and you're already in the fourth quarter and you've got plans of other commitments that you've already decided to make. What advice do you have to our listeners? For you have somebody who's accustomed to calling the shots and they're not accustomed to being told no.

Jeremy Williets: 11:56

I mean, I think this is I know you're using air quotes around hypothetical mark, but I think this is a pattern that Tom and I have probably seen at least once in our turns around the block. I know I've seen it and I'm sure Tom has seen it Exponential. We've seen it together. We did see it together. You're darn right, Tom. I think one of the real themes that we cover in our book is the idea of collaboration around priorities and alignment, and so I know it seems probably like a bit of a hand wave, but I think in the example that you're painting Mark, there needs to be a really come to Jesus quote unquote conversation between the person asking you to do the work, understanding what the deliverables are for that fourth quarter, and the people who care the most about the work need to get together to come to alignment on the actual priority list before just saying yes and cramming another thing in the proverbial pipeline.

Tom Cagley: 12:48

It really does have to be a systemic process and I know process for many of us is sort of a taboo word. But what the heck? Getting up in the morning brushing your teeth is a process, so I'm less worried about the taboo word. But it really does have to be a systemic approach. Because what Jeremy said about having that collaboration, that can't be just something that you magically say oh my, we've been asked to do something irrational. Let's have a meeting, let's collaborate and let's do that. That has to be. You have to start inculcating that into the culture such that when that happens not if it happens, but when it happens and if it isn't the CEO and if it isn't the person who is the founder of the company and it's going to be somebody else who has some surplus of power that's going to say, hey, we have to do this, knock everything else off. You do have to have a big people conversation about what you really are going to do and, very frankly, you're going to run into scenarios and both Jeremy and I have run into this, I'm sure you have too, mark where the answer is you know what we really do have to do. This. It isn't just crazy CEO or crazy founder over here coming up with something brand new. It really is important to us and to the market. Then you have to have a mechanism to rationally weigh the trade-offs and make a decision about what comes off and what does.

Tom Cagley: 14:29

I did an interview for the spamcast recently that'll run actually this coming Sunday, where a gentleman said you know, they walked into a company that had 30 major initiatives on the books that had to be done by the end of the year and it was 90 days before the end of the year and they hadn't started all of them, just 30, just 30, but they hadn't started all of them. It was not a really big company, but it was. What do you do? And the answer is well, let's at least pick the two or three that you're going to start and actually get done.

Tom Cagley: 15:05

But we've made that promise and that's because nobody had a mechanism to continually have that conversation across a period of time that those answers built up. It can't be when they walk in the door. You have to start putting that in place now and I think that's one of the reasons. You know, mastering work intake is, I think, pretty critical. Is it really does lay out that there are a number of layers within the organization that you have to put these sorts of checks and balances, these collaborative conversations in place so that, when things go off the rails, either know it and you have a mechanism of actually tackling it, without having to try to make up the rules right there on the spot.

Mark Metze: 15:56

I'm imagining some of our listeners are out there saying I hear what you're saying, this makes sense. Yes, we need that. But Jeremy and Tom, how do we start that? How do we get that into place? Yes, some of our listeners may say you know, I work at where people are very protective of their areas or their departments or what have you. So give us a little, fill us in with a little more detail on how to start this mechanism.

Jeremy Williets: 16:18

Sure, but this ties really nicely Mark to, I think, a couple of the activities that we've baked into the book, because it's not just a book, it's got some activities baked into it as well. And really the first activity that we have near the end of the first quarter of the book is all about understanding where work comes in to your organization or your middle layer of your company or your team. And it's with that understanding that we then build future activities in the book along, so that you have a map of how work is flowing and coming into the organization and into teams and into the middle levels, because without that you're kind of flying blind. You're either guessing or you're leveraging some other sort of mechanism that may or may not be the truth. So step one, I think, is to visualize and understand what's going on already before you can then start to work towards changing it is and, again, using other words, it is a mapping scenario where you do really have to visualize.

Tom Cagley: 17:16

You have to know, I think both of us and we're not trying to be primadanas, but we do believe that in most scenarios that you can lay down and say, hey look, we've got work coming in from five different directions, at five all at once or at five different times. How do you want us to sort that out? Those conversations are rational, regardless of political kind of ramifications. And you're lucky, mark, that you don't work in a political organization. I don't know that. I've done work in any organization that was less than 1,000 people. That wasn't horrifically political and office politics are not necessarily bad things, but people do work very hard but they are rational in most circumstances. So at least getting it, mapping out the current state, which that sort of approach that Jeremy went through, mapping that out and looking at the flows of work not necessarily the flow of the work, but how the work flows in is that first step at least in having a discussion about what a future state could look like.

Mark Metze: 18:35

Okay. So first step, we're going to map all of our different customers, stakeholders, users what have you and how the work comes in from the different areas or people. Now, how do we go about prioritizing the work?

Tom Cagley: 18:49

Well, that's where you wave your hands and run for the hill.

Mark Metze: 18:54

I mean, obviously they're going to say you open your wallet and say, hmm, if there were some way that I could be convinced it brings the priority.

Tom Cagley: 19:02

Well, a good friend of mine, alan Kelly, from over in the UK, actually does something like that. He does sort of shark tank kinds of workshops in terms of using that approach as a prioritization mechanism. And there are lots of different prioritization mechanisms, whether it's cost of delay, weighted, shortest job, first ranking. I think all of us can point at any number of different prioritization techniques. We would suggest that you pick one, two, something along those lines. But there are sort of attributes that are important. You have to be transparent. You have to do it in a more than once and done kind of scenario because, let's face it, we all know that the work is dynamic. There are attributes of a good approach to doing this and you have to adopt those. Again, you have to make it rational, you have to make it transparent. You have to be very careful that you don't let some of the bad political players get their way with it, because I think we can tell stories about that if we wanted to. Also, jeremy, how else would you go about that? Prioritization and sequencing?

Jeremy Williets: 20:21

into that. I mean just to add on to what you were saying, tom. I think the visibility, the transparency could have the ramification that it would not allow some of those terrible political things to happen because things are apparent. We've established a cadence to prioritization. We have maybe a tool set up that has our list of priorities in it. We're looking at that every couple of weeks to understand what that list of priorities are. The ability to circumvent that process to me seems like it goes way down if you have visibility and transparency involved, versus the old CEO comes up to your desk and asks you to do something. That's much more opaque, that's much more ad hoc and you're probably not going to say no to the CEO but definitely a lot different than some sort of cadence-based, visible and transparent process that Tom was describing.

Jeremy Williets: 21:09

The sequencing topic too, mark, just to add on to what Tom prompted me. There is a fascinating play in this whole equation too, and that's another topic that we think is sort of criminally not covered well in the agile literature that we know and respect. It's an idea that things need to happen in order. Right, it can't just be. This is the most important thing that comes first. Well, what about all those different infrastructure pieces that you need to have in place.

Jeremy Williets: 21:33

I'm sure all of us could think about examples where a technical leader, a product leader, came to us and said look, your team needs to do X. You take that really high priority thing back to the team and they go okay, great, we know this is the most important thing for us to do, but in order for us to do this most important thing, we have to do these three steps. These three steps might take us days, hours, weeks, months. Sequencing is often overlooked. The place I'm currently working right now in my day job is one that did not overlook sequencing, and it's been one of the main themes of my tenure here has been to be extremely cognizant of sequencing, because we are building products across multiple different disciplines, multiple different organizational silos, so if we did not have the sequencing pictures put together that we have, we would not be able to deliver products at all.

Mark Metze: 22:25

And so when you say sequencing, what relationship does sequencing have to do with dependencies?

Jeremy Williets: 22:31

It can have a huge part to play in dependencies. Again, though, part of power in Agile, I believe, is it gets people talking, it gets people relating to one another, it gets people sharing in a transparent and visible way, and so if we can understand the sequence of work that should end and we can see it on a picture which would be really great that can then give us the opportunity to identify some of those dependencies that you were asking about, Mark. And then there's plenty of different techniques that you can take. With dependencies, I mean, there's always a question of well, does it need to be a dependency? What can we do to break the dependency? Do we live with a dependency? Is the dependency acceptable? I mean certainly a thousand different questions you can ask, but the first step in all of that is understanding the dependencies based on the sequencing you have before you.

Tom Cagley: 23:15

But let's go back. Remember. We have a mantra and a common mantra that we want to prioritize and many people want to prioritize by value and just because something doesn't have the same, especially once you get into a relatively granular level. Something might not be relatively high value, but it is important and it may be a dependent or predecessor, successor, those sorts of things. It may have a specific order that it has to get done so that you can get to some of those high value stories.

Tom Cagley: 23:54

I did bank mergers back in the 90s and, very frankly, we had priorities because we were focused on the outputs.

Tom Cagley: 24:05

But there were any number of steps along the way, including things like changing the logo on people's little badges. Well, probably didn't have to happen, but it all had to be named the same thing by a specific day or we would fall prey to the banking regulators. Ah, you're confusing people. Well, again, not high value to go out and change people's name badges, but the outcome of rebranding the entire bank by a specific date that had been promised to the bank regulator. It had to get done in that order or it wasn't going to happen. So order and priority sequencing and priority related, but not exactly the same thing, we would suggest that you prioritize first and then you start to look at how you have to then modify that priority layering based on the sequencing to actually make it happen. That's also why it's important to make darn sure that you're collaborating and having this in a transparent fashion, so that all stakeholders, including the people who are actually going to do the work, have a voice in this process.

Mark Metze: 25:27

So I've got one more topic that I want to bring up along with this before we wrap up today. Through writing this book and through your experiences maybe you have a term for this, because when we name things, it really brings things to life and we can identify them better. How about the situation where your company or your development organization is asked to just deliver so many different initiatives and there's just this tremendous pressure, and so, in order to move from one to the next, to the next, to the next, the delivery team is really focused on just putting this here's my air quotes again an MVP together, which I know is a very bad word, and the situation I'm thinking of became we had to strike that from the vocabulary of the company but you give somebody an MVP and then move on to the next initiative. It's like, okay, well, this is okay for a first step, but when are we going to get the next that we really want? Oh well, we can't. We're already moving on to the next thing. It's too late now, and so you just rapidly, because you feel so much pressure, to continually deliver more and more.

Mark Metze: 26:36

It happened when we were replacing a legacy application that was very mature, very fully featured, very well received in the market. We were replacing that with a totally new solution, so the race was to put all the functionality into the new application that was in the old. Does that resonate, and do you have any magic terms for this spiraling situation?

Jeremy Williets: 26:58

I mean Tom used the phrase death march earlier, I think that's. I don't know that either of us can take credit for that. I don't know if we use that phrase in the book, but that sounds sort of like what you're queuing at there, mark. I mean this seems like a classic pattern that you've just described, whether it's the migration of one sort of legacy system to the new hot thing, the new hot technology, or the general problem of too much whip in your organization.

Jeremy Williets: 27:24

I think it's sometimes lost on senior leaders and companies that you know Development teams are finite resources, quote unquote.

Jeremy Williets: 27:34

I mean they're people, obviously. They're finite in their ability to do work at a high quality and they must be treated as such. One of the ways to treat people with compassion and empathy is to not make them work 80 hours a week, every single week, for the purposes of getting a product out the door that may or may not be viable in the marketplace. Again, for me and I'll let Tom answer here in a second, it comes back to really this example I needed to get a handle on the organizational whip first before focusing on the teams and hopefully through that organizational whip conversation some of those things can be cut off the list. Some of those things could maybe be rescoped and then the reality of the situation is a capacity of the system is going to be a big part of the conversation that this organization needs to have and so, armed with that particular piece of data, hopefully that would promote a rational conversation around what can actually be achieved and in what kind of time frame.

Mark Metze: 28:24

So it really is an extension of the, of the inability to say no. In the situation where you're telling people you'll put it on the backlog, that's giving them some hope. You're not directly facing them. Sometimes we are going to work on it and just giving people the response of oh well, the developers are actively working on it. That's another way to. I guess that's almost like a yes, it is true, but it's misleading. You know that the team is working on it, but we're only going to work on it for a short while and we're not going to be able to give the users what they really need. You're just going to barely scrape by just enough to get something done to say you've checked it off on your list.

Jeremy Williets: 29:03

And the scenario you're painting, mark, does get incredibly more complex when you involve customers in the conversation. The places I've worked at definitely want to please customers because, at the end of the day, customers pay the bills, and so if you find a customer that is very vocal, that has super specific needs, it can get really hard to satisfy their super specific needs when you're trying to satisfy the needs of an overall customer base.

Tom Cagley: 29:25

Maybe we worked at the same company, mark. I've been through this now four times in organization and interestingly enough and that's one of the reasons we just didn't focus this book at the team level, but not only the team but the product level and sort of the executive level of the organization. I can tell you the four times I went through this. One says a project manager, one says a program manager, once as a senior vice president at a bank, the CTO and the CIO didn't survive this scenario and a couple of them went through several iterations of attempting to do this onion skin thing, where they just did a little bit and then moved on to try to do something else at the same time. Lots of shell games.

Tom Cagley: 30:16

It is work intake, but it's not team level work intake that we're dealing with here. It's product or perhaps organization level, where those decisions are being made, where things are being put on the backlog. It's the board that says you will replace your core system with a new version, the next generation product, and they are probably not 100% cognizant of what is all involved in all of the things, but they're making and they say yes too often too. So it isn't just team saying yes, it isn't just people running around and going through at the team level or division level. It can be the same problem at the org level, where they say yes to everything. Now, on a positive note, we did replace a lot of CIOs and CTOs and sooner or later it got better Because, very frankly, you do it once or twice and somebody looks back and says oh, that's why that person is gone. They stop doing crazy things. People learn.

Mark Metze: 31:31

Yep, you touch the iron once, maybe touch it twice, and after that you sure do learn awful fast, right? But you do get to go to Pinket Valley cafeteria. Are they still around?

Tom Cagley: 31:42

No, I don't think they are.

Mark Metze: 31:44

I was going to Google that after we're done here and look yeah yeah, if they are, I'll reach out to them and see if they'll be a sponsor of the show Bingo. Well, tom and Jeremy, I really have enjoyed this. This has been a great session at the Agile Within. What's the best way for our listeners to get in touch with you?

Jeremy Williets: 32:00

They can find me on LinkedIn, Jeremy Willets. I'm in the Cleveland area. You can also look at my website, JeremyWilletscom. I've got some relevant blog posts up there, as well as links to where you can purchase our book Mastering Work Intake.

Tom Cagley: 32:12

You can find me on LinkedIn. My website is tomcagleycom. You can also look up the software process and measurement cast. It has its own website out there on iTunes and so obviously lots of ways to find both of us and myself. So we look forward to having a conversation.

Mark Metze: 32:32

Great, and we'll be sure and put those links in the show notes, but for now we're going to bring things to an end. So, Tom and Jeremy, thank you so much for being our guest and we will see everybody next time. Thanks for joining us for another episode of the Agile Within. If you haven't already, please join our LinkedIn page to stay in touch. Just search for the Agile Within and please spread the word with your friends and colleagues. Until next time. This has been your host, Mark Betts.