This week on The Digital Download, we’re talking about how Agile methodologies can be applied beyond the IT world to everyday business and personal situations. Mark Entrekin, Senior Agile Coach, Senior Program Manager, and Professional Speaker, will share how Agile can lead to more collaboration and better results - whether you’re in the boardroom or at home.

Join us as we discuss questions like:

* What are Agile principles, and how can they be applied outside of IT?

* Why do traditional change management methods often fail?

* What are the benefits of an Agile mindset in everyday business operations?

* How can Agile practices improve collaboration and efficiency in personal life?

Mark has over 40 years of experience leading teams and organizations through transformation and continuous improvement. He has successfully guided numerous teams in adopting Agile frameworks, not just for software but for creating impactful solutions in all aspects of business and life.

We strive to make The Digital Download an interactive experience. Bring your questions. Bring your insights. Audience participation is highly encouraged!

This week we were joined by our Special Guest -

• Mark Entrekin, Senior Agile Coach, Senior Program Manager, and Professional Speaker

This week's Host was -

• Rob Durant, Founder of Flywheel Results, a proud DLA Ignite partner

Panelists included -

• Tim Hughes, CEO & Co-founder of a DLA Ignite

• Adam Gray, Co-founder of a DLA Ignite, and

• Tracy Borreson, Founder and CEO of TLB Coaching & Events, a partner of DLA Ignite

Transcript of The Digital Download 2024-09-20

Rob Durant [00:00:01]:

Good morning, good afternoon, and good day wherever you may be joining us from. Welcome to another edition of the digital download. The longest running weekly business talk show on LinkedIn Live, now globally syndicated on the TuneIn Radio Network through IBGR, the world's number one business, talk, news, and strategy radio network. Today, we're bringing agile out of IT and into everyday improvement. We have a special guest, Mark Entreken, to help us with the discussion. With over 40 years experience leading teams and organizations through transformation and continuous improvement, Mark has successfully guided numerous teams in adopting agile frameworks, not just for software, but for creating impactful solutions in all aspects of business and life. But before we bring Mark on to the show, let's go around and introduce everyone. And while we're doing that, why don't you in the audience reach out to a friend? Ping them.

Rob Durant [00:01:10]:

Have them join us. We strive to make the digital download an interactive experience, and audience participation is highly encouraged. Alright. With that, Adam, would you kick us off, please?

Adam Gray [00:01:25]:

Hi, everybody. I'm Adam Gray. I'm cofounder of DLA Ignite and his business partner. I I was Tim always says famous for writing the book. So I think my claim to fame is that I've written, like, a testimonial paragraph and comment in Tim's book and in Rob's book.

Tracy Borreson [00:01:49]:

Adam is the most famous testimonial writer ever.

Rob Durant [00:01:54]:

There there we go.

Adam Gray [00:01:55]:

Yes. We've we've

Adam Gray [00:01:55]:

all gotta have something, haven't we? Let's be honest.

Rob Durant [00:01:59]:

Well, thank you, Adam, and welcome. Tim, thanks for joining us. Welcome.

Tim Hughes [00:02:05]:

Thank you. Welcome. Welcome everybody, and thank you. My name is Tim Hughes, and I'm the CEO and cofounder of DLA Ignite, and, Adam's, business partner. And and I always say, this which is why it's part of the joke that I'm famous for writing the book, Social Selling Techniques to Influence Bars and Changemakers.

Rob Durant [00:02:28]:

Excellent. Thank you. Tracy, good morning.

Tracy Borreson [00:02:32]:

Good morning, everybody. Calling in from Calgary, Alberta, Canada where it was 7 o'clock in the morning. Who am I? I'm Tracy Borys, founder of TLB Coaching and events where we're all about people not doing crazy stupid marketing, but doing really smart strategic marketing instead. And I am a proud partner of DLA Ignite, and I have worked in software for quite some time, so I've experienced the agile methodology in person. And I'm super excited today to see how we can bring that into our everyday business.

Rob Durant [00:03:09]:

Excellent. Thank you very much. We see Bertrand and then we don't. So when he comes on, we'll be sure to introduce him. Bertrand, you are still welcome to join us. Myself, I'm Rob Durant, founder of Flywheel Results, a proud DLA Ignite partner, and I am famous well, not quite famous Yeah. Yeah. For writing the book, The Social Enablement Blueprint, Stop Pitching and start selling.

Rob Durant [00:03:43]:

Alright. With that, as I said,

Tracy Borreson [00:03:48]:

think Jim has something to say.

Tim Hughes [00:03:50]:

I just got a note from Bertrand on Slack, that he's Oh. He he's got connection issues, and he said he can't join us.

Rob Durant [00:03:57]:

Oh, I'm sorry to hear that. Okay. Thank you. This week on the digital download, we're speaking with Mark Entrekin. Mark will share how agile can lead to more collaboration and better results, whether you're in the boardroom or at home. So let's bring him on. Mark, good morning, and welcome.

Adam Gray [00:04:20]:

Good morning,

Mark Entrekin [00:04:21]:

Mark. Good morning, everyone. How are you this morning? It's great to be here. All these happy faces. You guys are awesome.

Rob Durant [00:04:28]:

Thank you. Mark, let's start by having you tell us a little bit about you, your background, and what led you to where you are today.

Mark Entrekin [00:04:38]:

Well, that's a long story, Rob. That may take the whole time. I just want a short story. I I have been in IT since the seventies and just have loved it so much. It's been a truly awesome learning experience to go from the days. If you remember the little computer card, we actually used to have to type on those What's going on? Yes. And going to college with that kind of process was very interesting, and then to see the growth that we are to today. But I have a bachelor's degree business information systems, a master's degree organizational management, lots of experience going from company to company as a consultant, learning about the old ways of waterfall and how that worked, but things didn't work well because everything was running too late.

Mark Entrekin [00:05:21]:

Couldn't keep up couldn't keep track of all the processes and the long term situations that occurred because you had to get everyone involved. You had to have meetings. And then I learned about Agile, and I love what people call agile methodology because that's not what agile is. Agile is a framework of rules and processes to put together. Scrum, Kanban, DSDM, XP, and all the others. Those are our methodologies of how to use agile. Agile is about growing from a baseline that we have I think now have taken apart, but we'll go into that in a minute. More about me.

Mark Entrekin [00:05:59]:

I am based out of Denver, Colorado, but currently, I am in Southern Mississippi with family and enjoying the nice weather down here, high humidity. But it's been a great life, and I'm breaking more now into more speaking and coaching and consulting in the process, helping people with agile as well as achieving unity or creating unity so we can achieve unity in the workplace and at home. Excellent.

Rob Durant [00:06:27]:

Thank you very much. So, Mark, I wanna start with a foundational question, and I believe you started to address it, but but let's get right into it. What is meant by agile in the IT realm, and what are agile principles?

Mark Entrekin [00:06:44]:

Okay. We have there's 4 principles to agile, but let's go to the IT world first. Let's kinda talk about that. Because when agile was written many years ago, it was written for the IT world. Everything was about programming and requirements and software, and it works very well. And I do support companies transitioning from the waterfall world into the agile world because it does work in software. What I have done is moved it a little bit away from the process of being so computer literate to being a little bit more open to how we can use it because we want to get around ideas such as requirements or software and turn software into solutions. Because what Agile does in those four principles, I call them the crew, customer collaboration, responding to improvements, empowering individuals and interactions, and working solutions can be used very well in software, but they can also be used very well in our daily life.

Mark Entrekin [00:07:53]:

So many things that we do are crossed over from the business world to the personal world. Who is our customer? Our customer could be our friend. Who are we working with, and who are we building with? That type of collaboration is beneficial for all, and we don't talk enough. We don't share enough. But we want more cost customer collaboration, more friendly conversation than legal or contract negotiation as Agile started with. Is it we're talking about Agile. I'm talking about the manifesto. And I don't know how long you want me to go here, just rather than answering your question.

Mark Entrekin [00:08:31]:

But I'll go with just these last 3 just quickly because you want to be responding to improvements all the time as far as the second one, over following just plans. You wanna respond to improvements over pacifying comfort levels because that's too much of what we do in the waterfall way. We have a comfort level, somebody well, we've done this before. I did it at another company. Somebody else did it, and we just follow those processes instead of working on continual process improvement. We want to empower individuals. Everyone, empower the individuals. Empower the interactions between each of us.

Mark Entrekin [00:09:04]:

We wanna do that more also over pacifying those corporate levels in our processes. Working solutions that goes for all of us in what we do. What we're doing here on this meeting this morning with us. What is our agenda? But won't working solutions over reading nonsense that doesn't make sense to the author either, and that's what we have or had in a lot of our old documentation. The comprehensive documentation, who could read there, who who could understand it? Look at my newsletters out of my site, www.markettricken.com, you'll see I even talk about legalese, and we need to get rid of legalese and put it into English ease so we can all read and understand the laws that we're supposed to obey.

Rob Durant [00:09:47]:

So, Mark, I I've heard you mention waterfall, and it's been replaced by agile, but I have no IT experience. K. I don't know what you mean by those terms. Is that basically the playbook that you follow for developing software?

Mark Entrekin [00:10:08]:

Yes. Great question, Sarvita. Thank you. The waterfall way came out what's called the PMBOK, project management book of knowledge, PMBOK, And there were well, there is a large book. It still exists. Waterfall still exists, and many companies are still utilizing waterfall on a day to day basis. Some people say you can't do agile for everything. Well, it's everybody has an opinion.

Mark Entrekin [00:10:33]:

So waterfall is the process of doing your SDLC, your software level software development cycle SDLC. And you go into requirements, you go into design, you go into programming, you go into testing, and you do all those in specific boxes. And one can't can one can't start pretty much till the next the last one has ended. It's just first in, first out, sometimes called FIFO. So in the software process, it's for people who have maybe used some spreadsheet software and written functions in there. You have a field, a column here, and you want something here. You write in there, take a 1, multiply it times 4, and that's where it is in column b. That is a theoretical program or function in the simplest of terms.

Mark Entrekin [00:11:30]:

Now, of course, when you get into rocket travel, there's so many more calculations and equations involved than just saying a 1 plus 2 is b 2, but it's all still an equation that's used to build one from another. And again, that waterfall world, that had to be completed before anything else could be done, and that could take months. The design could take months. The programming could take months. The testing could take months, and it took a long time to get any kind of project completed. So when you're putting this all together and you have these large projects, think of banks, think of rocket science, think of anything a company does, by the time the program is completed, when you got months months months, the software product that they had designed is probably out of date because someone else has completed their project, their program, and it's ahead of yours. So then you go back and you start reprogramming. Until you reprogram something, it takes more time.

Mark Entrekin [00:12:34]:

In the agile philosophy, you're doing more of taking your highest priority to satisfy the customer. You wanna do that through rapid and continuous delivery of valuable solutions, not just software. So what that means in let's take it in what's called the scrum world, which is a method that we use within agile, the methodologies. You put together daily stand ups to go through what you've written of those requirements, which are called started with stories. And, Rob, one of the thing well, all of you, but one of the things that we have problem with today is just all understanding a term and then someone not wanting to change the term. So using that word like stories, for example, you write, as a user, I want this so that. You have your what, when, and why. So who, what, and why.

Mark Entrekin [00:13:26]:

So you wanna make sure you find a result to the process. So in the scrum world within the agile, which, again, you're getting your highest priority first, you put together 4 ceremonies. One of them is to create those stories in a way that you say as a who's the user? I want, what do you want, and then why? Why do you want it? So as you're putting it together, you're solving that why in the process. Can you give

Rob Durant [00:13:54]:

us that story framework again, please?

Mark Entrekin [00:13:57]:

Keep the story framework. Okay. The story is

Rob Durant [00:14:00]:

As a

Mark Entrekin [00:14:01]:

as a whoever you are, who's the person that wants this? Are you an engineer? Are you a customer coming into a retail store? Are you a parent wanting your child to do something? Who is the person that's making this request? Sometimes it can be called a requirement, but the we take it as a story to ease it up a little bit, but as a end user

Rob Durant [00:14:26]:

Ideal target audience, end user. Sure.

Mark Entrekin [00:14:29]:

I want what do you want? I want your room clean. I want a new field on my screen, and I want it red. I want it to take numbers. I want there's all kinds of things you could put with it so that

Rob Durant [00:14:42]:

pause there. Please. I like that because in sales, so often we talk about people's pain point. What's the problem? That doesn't talk to me about the problem. That talks about my ideal desired end state. What do I want? Well, of course, I want the problem solved, but what do I want out of that? So I like that. As a, I want and then what was that third element of the story?

Mark Entrekin [00:15:12]:

So that. What's your why? What you're putting it together for? I want so that I can enter account numbers. I can get the toys off my floor. I can do whatever I need to do to complete the the what for that entity, that person. And I want to keep some of the larger words out, but the as a, that user, that customer

Rob Durant [00:15:43]:

keep the larger words out. I'm simple.

Mark Entrekin [00:15:48]:

So as that end user, I want whereas I want what's the value? What's the solution? Where is the value? Where's the value? And then so that here's what I want the end result to be. And it goes, well, it doesn't matter what why, but, yes, it does matter why. Because as we get into why, what we're doing something, we can all pitch in and continue to pitch in about what we're accomplishing and why we're accomplishing it so we can improve it. So, again, we have those stories to start with, and then we have what's called story review. And we'll go through

Rob Durant [00:16:24]:

this you go into the story review, let let's stick with story for a minute. Tracy, I wanna bring you in here. Yeah. You said you have, background working with IT organizations, and I know you like a good story.

Tracy Borreson [00:16:38]:

I do love a good story.

Rob Durant [00:16:41]:

Tell me a little bit about what you heard. Were you ever exposed to to this, plan of action?

Tracy Borreson [00:16:48]:

Okay. So what I'm experiencing as Mark is explaining the difference between waterfall and agile is that I think the software organization I was working for was using the waterfall methodology, but calling it agile and, like, using a Kanban board and scrum, which are agile methodologies in the waterfall principles. So now I'm honestly a little bit confused about what's going on there, Because this is actually stuff like for quite some time, I became like a a a a default product manager for the product because I was responsible for the marketing of it and telling the story. I did all of the customer interviews and onboarding and all of those types of things. And so and story has always been important to me, so I was, like, constantly trying to pull the story out of this. But, like, we did not have this story formula that we used for any of the development that we did. And I'm thinking right now, like, how does stuff even get done? You know, the way if you don't know the story because you get caught up. I remember having this conversation, like, it took days going back and forth as to, like, what color this button should be on the site.

Tracy Borreson [00:18:11]:

Right? And me, I'm like, I I mean, we need a button to do the thing. But, like, who cares what color the button is? Or we could test the color of the button to see if it makes it easy. Like, why are we spending so much time? And, like, if we had tried to put this a story together for the color of this button, I'm pretty sure we couldn't have come up with any kind of reasonable story for who it's creating value for and what end result they're going to get. So I'm just very excited about this. And even from a a, like, business perspective, like, most of the work I do now is trying to help marketing teams convert from a a cost center into a performant like, a revenue engine. And, like, this story, folks, this is the why. Why do you do that? Why do you want a revenue generating engine out of your marketing? Do you care, or is it just because someone told you at some point that you should do it? I think there's, like, figuring out your real why, connecting it to a customer need. Right? Like, it's clearly the beginning part of the process, but I feel like it's being missed a lot of the time.

Rob Durant [00:19:20]:

Okay. And I think that hints to the the topic for today. Bringing those agile elements out of the IT department and pointing out where everyone can actually apply that.

Mark Entrekin [00:19:36]:

And Rob, can I touch on something that Go for it? Good touch on something. Tracy makes a lot of great points in what she was talking about because so many people and of course there are 99 companies probably that has a scrum certification or agile certification or Kanban certification or XP certification, and everyone does it differently. And she made a lot of good points of how each company and sometimes departments within companies want to do it differently. They don't think things all the way through the process to where they're using the stories themselves to solve their own story problem. I think she made a lot of good points there, but I hadn't heard of that before. And that's so loud in what she's saying, and she's right. Because that story has got to be the start of what you're doing and it doesn't matter what you call it. Some people want to call different things, but that story of as a.

Mark Entrekin [00:20:34]:

First, who needs this? What do they need and why do they need it? She mentioned that color. That goes right back into to the process of someone has to have be the one that decides that color, and they need to get together in those and then vote. And that's what we do in the story planning is you get into the process of saying, what do we want? And then when it comes down to the color, who decides the color? We get together and we say, we're in that's in the story requirement story process, and you say, Who is the person here and why do they want this? That's the so that, and that's where that color comes about. Am I making sense?

Rob Durant [00:21:14]:

Sure. Yeah. Adam, I think I interrupted you earlier. I apologize.

Adam Gray [00:21:18]:

I was just gonna say, in the run up to this, I did a little bit of little bit of googling. Now, obviously, anyone that that's gets to my age has heard terms like agile and scrum and waterfall and yada yada, all of these different different terms. So I thought, so so I I thought the premise of the conversation today was a really interesting one, you know, using these techniques outside of their normal usage. So I thought I I need to kind of educate myself a little bit. So I I I did a bit of research into what agile is, and there's a load of terms there that are kind of very software focused. But it said, agile is a good choice for projects where managers can't know all the details at the beginning. Projects span large time frames. There's a high risk of unexpected concerns.

Adam Gray [00:22:13]:

And I thought about my experience in the workplace, and I thought, well, that's that's kinda like everything that happens in the workplace. Because you start being largely ignorant of what it is that you're buying or doing, and then as you go through the process of starting to implement that change project, whatever it function of the business it's in, you learn stuff and you realize, oh, that preconception I had at the beginning actually doesn't fit as well as this idea that I now have, and that further develops as you go through it. And I thought, actually, this is a really interesting metaphor for how life works. You know, because you go to school, you study something, and what you study you think you think is gonna lead you to place a, and none of us ended up, where we thought we would end up when we were 18 years old. We've all ended up somewhere entirely different, because as we have as we have learned things, as we have as we have gone through the process of of deploying changes in our education, in our career, in our workplace, in our projects, we've learned more stuff, and we've thought, actually, I'm now starting the journey to that destination. Well, a, the destination has changed maybe, but, certainly, the route to get there has changed. So this seems like this is a perfect way to to manage your own life, your career, your everything you do.

Mark Entrekin [00:23:37]:

Adam, that is so well said. Well, thank

Adam Gray [00:23:40]:

you. I'm I'm I'm off now.

Tracy Borreson [00:23:44]:

I have a question about that, though, because I feel like, especially from a software perspective, there's a a defined product of some sort. So there's kind of this idea that we're finished something, which is why I think there is a it's still almost a tendency to think waterfall. Right? Like, I'm gonna come up with this, and so I'm gonna create the scope. I'm gonna do the things, and then I'm gonna get the thing. But as Adam said, life doesn't work that way. Right? We learn. We grow. Scope changes.

Tracy Borreson [00:24:20]:

This is why there's terms like scope creep that exist. And so what would you say, Mark? Is this is there, like, a mindset shift or something that we need to make in this concept of, like, a product or a solution being finalized versus, like, we're opening the door to something that has every intention of being continuous improvement?

Mark Entrekin [00:24:45]:

Tracy, it's it's awesome. And thank you for leading me into that because that's part of the things if we took it the scrum, which is the methodology from the agile framework. Scrum puts us into the point of putting those stories together, and the word I was losing a few minutes ago is story refinement. Always refining your stories. But then you have those stories and then you pick a period or it's called a sprint or an iteration to complete a specific selected amount of stories. This is what you do on a period by period, sprint by sprint basis. So in the the scrum part using the Agile Manifesto as your framework, the methodology itself is using scrum so that you have a daily stand up, you have a review at the end of this sprint, then you have a retrospective in the process. I'm forgetting one of them.

Mark Entrekin [00:25:36]:

There's 4 of them. There's 4 ceremonies in there. You have your daily stand up that you go through every day. You spend 15 minutes and you talk about what each one of those stories, what have you done? What was done yesterday? What do you plan to do today? And what are your impediments or your roadblocks? You go through it to find out what each of those are every day to make sure you're accomplishing something. So by the end of that sprint, generally, a sprint is considered 2 weeks. It can be 1 to 3 or 1 to 4 weeks, but you define that right up front. So each of those stories has to be able to be completed, broken down the minimum viable product or service so it could be completed in that sprint. That 2 they'll usually do 2 weeks.

Mark Entrekin [00:26:19]:

And so you get those done and at the end of that sprint, you go through what's called a review, some call it a demo. But it's a review because there's more discussion, and we'll talk about that in the retrospective in just a second. But at the end that you do a review of it, and in the review, you're showing what's completed. So you're showing the child showing the parent the room. Here's what's completed, and I've got what I've completed in my room. Most of those should be done in a day, and that's okay, but some may be longer. The software product, you're wanting something done on your screen. You want that field completed.

Mark Entrekin [00:26:54]:

You want it to do something. So at the end of that sprint, you show your end user the as a what is accomplished. And not only that, during that sprint, you're showing your completion ratio through that daily stand up. I want that field on my screen, so you're saying I'll have that field on my screen done in after 3 days. And you're showing them how much you've done on a daily basis and then when it's done. And of course you have situations where there's dependencies from Sprint to Sprint that goes in the process. But that's what you're doing in there on all of those stories. You're gonna have done in that Sprint.

Mark Entrekin [00:27:35]:

1, 2, 3, 4 week period, no longer than, usually 2 weeks. But at the end of that Sprint which you have also after you review is called a retrospective. And in that retrospective you looked at what worked of all those stories that you put together, how how many of them did you complete, what didn't work, how many didn't complete, and then why. And you may even create stories at the end of that retrospective to fix the problems that didn't work during that last sprint. So that retrospective is very important. So you're putting these together, you're doing all of your work during that sprint, that iteration, and that's usually that 2 week period, and you have those identified stories where the as a, the entity, whoever that might be, can say, yes, that's not done. Yes, it is done. Or wait a minute.

Mark Entrekin [00:28:27]:

I thought I said the color was blue. You gave me a light blue. It's still blue, but that just shows that the refinement of that story was not done well enough to clarify what color blue that you may have wanted. That's why you also had that retrospective at the end of your sprint.

Rob Durant [00:28:48]:

So, Mark, I I wanna bring this out of an IT centric realm, but let me make sure, I understand. If I heard you correctly, Waterfall was the method of developing software that was very linear. We do a until a is complete, we don't look at b. Agile, which what I I used to think was just willy nilly. We we take care of the loudest problem first, actually has some intent behind it. So now I'm talking in the world of, of business change in general. Why do traditional change management methods often fail?

Mark Entrekin [00:29:34]:

That's another that's a basis of what agile and scrum and kanban and XP and DSDM, all of them come from because there's no you may have a requirement. You get all this design requirement, and I think it was Adam was saying earlier, something changes along the way. When you've got something that large and something changes, the impact to the rest of the process is many times overlooked. Too many times waterfall is the seed to procrastination because you can always put it off. It's got you got 3 months to do this. So for the first two months, two and a half months, you're kinda throwing things together, but it's this last 2 weeks and that's where the big overtime came in of getting them done. So in the Agile Scrum, and then the only difference between the Scrum and the Kanban is Kanban, it doesn't have this the full cycle of all the ceremonies of the the story creation, the story refinement, the daily standard, things like that. Kanban just looks at what's we are we doing today, what's done, what's in test, or what's what's being worked on, what's in test, and what's done.

Mark Entrekin [00:30:47]:

But that's the process of you completing these stories, these requirements on a day to day sprint to sprint basis. Where more in the waterfall, you can have things stretch out for again months before you see any value. And then you have to look at, well, what's the value now that the months have passed or when you're using the more the Agile philosophy of the highest priority to satisfy the customer through rapid and continuous delivery of valuable solutions. That rapid and continuous delivery is what makes the difference between using Agile and using Waterfall.

Rob Durant [00:31:23]:

Help me map that over to other business operations. I'm a sales leader, and we're going to change our go to market practices, and nobody wants to change the way we're doing things. Or I am an HR leader, and we are going to change our business practices regarding remote work. Change management is typically difficult and often fails. What can I learn from the agile process and put it into 12 year old speak for the rest of the organization? Amazing.

Mark Entrekin [00:32:03]:

For Tim. Okay. First, on on the process, you said let's just take one of my HR, whatever. You're gonna do you're gonna do a you're gonna make some and one of the things we look at is or that I preach on is a change is short term and improvements long term. We have to make changes in the process, but we'll make sure that change is part of the improvement. But let's say you're taking an HR and you have a program that's gonna happen in 3 months, 12 months. You don't use that waterfall process of saying, well, here are some things that we're going to do and we'll get them done in 3, 6, 12 months. And then 2, 5, or 11 months later, you're not done.

Mark Entrekin [00:32:41]:

You don't have you're not where you wanna be. If you use the Agile manifesto for the framework, you're gonna take the HR project and say, what are we gonna do? Then we take all they wanna do and then we break them down. Break them down into the the smallest viable product or service. So you wanna HR, you said, well, we wanna talk to our employees more. Okay. Well, boom. There's a story. As a manager, I want to talk to my employees more so that why do you wanna talk to them more? You break it down.

Mark Entrekin [00:33:19]:

They say, well, there's several reasons. Boom. There's multiple stories. And then you complete those again in that 123, no more than 4 week period. You put that process of what you're going to do in that new HR program and you break it down so that it's achievable. Each one of those stories, each one of those requirements, each one of those needs, each one of those wants, and it's completed in that period. And then you have all those things that build up.

Rob Durant [00:33:47]:

Come in? Where does measurement come in in the process, especially outside of the IT world? How do you know if you're on the right track, and how do you know when you need to maybe modify the track?

Mark Entrekin [00:34:00]:

Beautiful. Beautiful story. It's a situation of what we call story points, and then you go into this earlier. But when you create a story as a I want so that you look at the difficulty of the complexity of that story, of that requirement. And in the agile philosophy, agile manifesto, it doesn't get into time. And a lot of people when they go into scrum, they say it doesn't get into time. But the only problem with that is time is our only definite. So you do have to do time, and you wanna but when you do the story and you do story pointing, there was an approximate point.

Mark Entrekin [00:34:38]:

So one point would be a minor a minor a very minor change. It would mean it would take me half a day to do a one pointer. It would be and some people are gonna fight this because, no, you don't wanna put time in there because they didn't put time in in Agile, and that's true, but everything comes down to the time. So you might say about a half a day. That means it could take 1 hour, it could take 5 hours, But you have a time limit on how long it's gonna take you to get that done, and that's why in a daily stand up, through every theoretical morning, when you get together and say, I worked on this, got this done, here's my impediments, here's my problems. You wanna do that on a daily basis to see what you're accomplishing, and you do that based on the points I'm talking about to say, okay. I already did that as a 3 point. I expect that'd be done in a day and a half.

Mark Entrekin [00:35:32]:

It actually took me 2 and a half days, so my pointing was wrong. My measurement was wrong. Or it could be that, hey. I got it done in a day, so I'm working on something else. And in your sprint, in your iteration, in that sprint planning, you have multiple stories to work on. So let's say it only took you an hour and a half, you've got another story right there to jump right into and start working on that you've measured again with those points. That's where your measurement comes in. I went through a lot of things there, but to answer your question on on the timing, every story has points to measure about how long it's going to take.

Mark Entrekin [00:36:11]:

But the benefit to it is you're going to have 1, 2, 3 stories, maybe up to 4 or 5 maximum in a sprint because you get too many stories, you get back into the waterfall way of just too much going on. It's hard to keep up with everything. But you know that during that sprint, you're gonna have a couple three stories to work on. You complete early, you go and start the next one. If it takes a bit longer, then you make sure you will log that, talk about that in the retrospective at the end, but you do what you can to get those stories accomplished and do complete what you can. And if you don't get something done, then you make another story to complete it in the next sprint.

Rob Durant [00:36:54]:

So, Tracy, you said you've done some, product management, and no doubt you've been part of just change management within organizations. How does your experience with those align to what Mark was saying regarding the agile methods that he was discussing?

Tracy Borreson [00:37:18]:

I'm okay. So the example that I'm thinking of is CRM implementation, which I think, like, from a

Mark Entrekin [00:37:25]:

large organization.

Tracy Borreson [00:37:27]:

Yeah. And it's, like, these things are always I've never actually seen one that's been run as agile. Like, every single one has been structured as waterfall. Like, we have this CRM. We're moving it to this CRM. We have to take the data out of this one. We have to build the data structure in this one. We have to input the data into that one, and that's very, like, linear process.

Tracy Borreson [00:37:47]:

And then what happens almost every single time is that the new CRM looks exactly like the old CRM and people don't use it any differently except we spent $50,000 in doing this switchover. And but when I think about it, I'm like as you're talking, Mark, I'm just thinking of, like, all of the things, all of the projects, all of the changes, all of the product design that I've been through that do not have stories. And I feel like this is the big missing piece. And I don't know if it's just, like, I'm taking all of the votes. So maybe it's just because I have, like, identified as a storyteller. But, like, even this concept of story pointing. Right? Like, I'm imagining the story being the 3 little pigs. Right? The the 3 little pig, there's there's a beginning of the story.

Tracy Borreson [00:38:36]:

There's the end of the story. There's stuff that happens in the middle. But there's a straw house, and there's a log house, and there's a brick house, and there's a big bad wolf, and there's, like, points of the story. Right? And when we are telling the story, we know if we've missed a point. Right? Like, we can tell that we've missed the point because we know what the story is supposed to be. And when we're talking about nursery rhymes and fairy tales, then maybe that seems easy to understand. But when we look at our business process and improvements and changes, like, do we actually know the story? Like, who is this for? And, like and and to address your question too, Rob, like, how do we track that we're going there? Because I can also track in software that we've delivered a lot of features. I can deliver a lot of features and not go anywhere on a story front.

Tracy Borreson [00:39:30]:

And so, like, how do we make sure that it's actually coming back to something that is going to add value and and have that rapid and continuous improvement? Because sorry. I'm just, like, thinking all the things.

Mark Entrekin [00:39:44]:

You guys are making too many points.

Tracy Borreson [00:39:46]:

It's so genius because, like, 1, what other department I would love if someone is watching the show and they actually have a department that's not IT, who runs on 2 week sprints, who can actually show the business that you are getting something done in 2 weeks. Right. Okay. Because I would say I have not seen a marketing department that does that. We would be lucky in general to show someone in a year what we have

Mark Entrekin [00:40:12]:

done. Exactly.

Tracy Borreson [00:40:13]:

Like, that's nuts. And if you're an HR if you're a HR, which is the example you guys were giving, and, like, you actually wanted to, you were the management team and you knew why you wanted to hear more from your employees, wouldn't you want to be able to prove to the organization that you did something about it in the last 2 weeks? Like, I mean, I know that doesn't necessarily mean we complete, like, the whole novel. Right? But we complete the stories as we go. And how then my brain says, like, oh, when people are like, have software companies that are startups and they are, like, making all these milestones for the business and they're saying, we're going to develop this feature. Who cares? Shouldn't we know what the story is?

Mark Entrekin [00:41:01]:

The thing that we

Tracy Borreson [00:41:01]:

are getting out of that.

Mark Entrekin [00:41:03]:

If I could add to that, because I've I left out one part of it. Every story has what's called acceptance criteria. So that when that story is being worked on, there's certain acceptance criteria they're measured by. And when the story is done, all that acceptance criteria, like you're saying, your end user working in HR or in the CRM, they know what that acceptance criteria is when they turn it over to software team, whoever they're turning it over to, what that acceptance criteria is, and that's acceptance criteria that's checked off when it's done. So at the end of that 2 week period, they know what's going to be done and what they will have to use that next day.

Tracy Borreson [00:41:43]:

Well, and I think Sorry. I just wanna share a quick thing about like how I see that in marketing because like it still sounds like kind of a software type of example. But, like, if we are trying to create digital ads. Right? Like, one, let's set up the story of why we're trying create digital ads. But then if we have these, like, really clear acceptance criteria that allow us to all understand when this story is is making progress, right, then we are actually tracking against the story. Now we have data points. Again, like, Rob, you were talking about. We have data points, and they're unique for each story.

Tracy Borreson [00:42:24]:

But we have data points acceptance criteria to track that, and that is relevant for any kind of business workflow.

Rob Durant [00:42:34]:

Okay. Let me go ahead. I I wanted to ask

Mark Entrekin [00:42:36]:

Go ahead. Yeah. Go ahead.

Rob Durant [00:42:37]:

Tracy Tracy talked about implementing a new CRM, and at the end of the day, the new CRM looked just like the old CRM. I know in your past experience, you both work for an organization where you sold large software products. What did it look like on the other side of that relationship where they were implementing something and they had to deal with change management. And were they looking to you for support, the steps throughout the process, or was it sold and done? What did you observe and maybe where could these agile methodologies have helped support the sale?

Tim Hughes [00:43:27]:

I think that, yes. And I and I think from what, Adam read out earlier on, most definitely, agile can can help within non IT, environments. And from what Mark has explained, most definitely, you know, there's a there's a very clear structure here to support change, because changes is you know, if moving moving one CRM to to another CRM is relatively simple. Okay. You're gonna spend $50,000 and you gotta move these bits, the IT and the data across, but actually, it can be done. The big difference is actually getting, people to use the CRM in the first place, which is a a change, has changed consequences. You know, moving people from I'm not filling in the CRM because it means nothing to me to I can't wait to wake up in the morning and fill the CRM in is is a is a okay. Mark, not not quite quite get them to people like that.

Rob Durant [00:44:25]:

Said no one ever.

Tim Hughes [00:44:27]:

But but

Tracy Borreson [00:44:28]:

I've never heard anybody say that.

Mark Entrekin [00:44:30]:

But that

Tim Hughes [00:44:31]:

change is is is is is is fundamental to to getting people to use the system. And and so what what Mark's saying is is spot on. Yeah.

Tracy Borreson [00:44:40]:

But also I think it speaks to the difference between the change and the improvement that Mark outlined. Right? Like, we can change a lot of things, and just by changing something doesn't necessarily mean that it's an improvement. So how are we making sure that if we're going to go through the effort of the change, even if it's a seemingly small change But, I mean, for some companies I've worked with, a $50,000 CRM shift is a big change. And so if we're going to do that, we do want to make sure it's an improvement, but a story that will make that an improvement instead of just a switch.

Mark Entrekin [00:45:16]:

Yeah. Very well said. And if we just take it out to something simple, and everything does break down to something simple, even rocket flight. But let's just take a child cleaning their room. You say, Sundar, whatever, go clean your room. Okay? The son, daughter, goes in there and moves some toys around. Okay. Well, that toy movement was cleaning the room to the child.

Mark Entrekin [00:45:39]:

Well, that's probably not what the parent wanted, But the process is in the Agile manifesto, we'll talk about the team, the solution delivery team, must work together daily throughout each iteration, each sprint to value accountability and responsibility based on those stories and that acceptance criteria. So what do you want your CRM to do? Where is that improvement? You make those small changes, as Tracy's saying along the way, to build up to that improvement. So, again, delivery team must work together daily throughout the iteration to value accountability and responsibility. That child needs to vacuum the floor, pick up the toys, to wipe off the desk, whatever it may be. And that's the same thing for putting a rocket ship together together. And I have worked on with companies in in Lockheed Martin in that process. It's all breaking everything down into a minimum viable product or service. What does that CRM need? What does that HR team need? Break it down and make those stories completable based on that acceptance criteria.

Rob Durant [00:46:54]:

I wanna come back to the the sales perspective. That's my bias. That's my bent. Adam, as one who sold large software deals Mhmm. Did you already have in place some, form of helping your customers with the change versus improvement? And if so, what was it? And if not, do you see value there for a salesperson?

Mark Entrekin [00:47:27]:

A lot of ways with the sale because what part of the sales process are you? Because if you're selling software, are you selling a full package or are you selling an improvement to a package? So, yes, that part of this is something that is changed, which is a short term, and it's something you're gonna end up.

Tim Hughes [00:47:49]:

Adam, the question was actually directed at you. Right.

Mark Entrekin [00:47:55]:

Apologies.

Adam Gray [00:47:57]:

Ask ask me the question again.

Rob Durant [00:48:00]:

Regarding, change versus improvement, What is the seller's responsibility in that regard? And did you take that responsibility? Did you have, practices in place to help you with that? And if not, do you see value in doing so?

Adam Gray [00:48:25]:

I I think that the challenge that you have is that, every buyer is different. And I I think to to invest a huge amount of effort in engaging with the buyer around a product or a sale runs the risk of you formulating all of your strategies based on an interaction with 1 individual organisation. So I I see this methodology as being a fantastic way of streamlining internal practices, either within your own organisation or within your own life, as a way to go from where you are to where you think you may want to go. And I think that that's the that's the key part, isn't it? It's like when you set out on the journey, you know you're heading east. You don't actually know where you're heading, but you know you're heading east. And as you go down the road, you you you redefine what your objectives are because you can't possibly have all of for a complex need, you can't have all of the information at the beginning. And, certainly, I I would see real risks in terms of me, engaging with Rob as a buyer and me formulating all of my sales strategy on how Rob responds to to what it is that I'm trying to do. Now did clearly, you you may completely disagree with that, and you might go, well, the customer's always right.

Adam Gray [00:49:52]:

And you but, but I I think that that so often, what we see is we we we see organizations and individuals looking for a one size fits all. I had the following conversation with Rob, and therefore, that's how the conversation will play out with everybody. And I think that that's probably an unreasonable expectation.

Rob Durant [00:50:14]:

Mark, we have time for one more question. So I wanna bring this from IT, from business, down to the very personal individual level. How can Agile help with things like personal productivity and time management?

Mark Entrekin [00:50:32]:

One of the biggest I I love that question too because we all encounter this wonderful term called procrastination. We put things off And one of the biggest functions, foundations of Agile is simplicity. Maximizing the amount of work not required is essential. Maximizing the amount of work that's not required is essential to how you accomplish whatever project, task, program that you have in front of you. What are you doing that is essential, and what are you doing that's more of the old waterfall? Well, we need meetings. Well, there are meetings in Agile with your scrum combo, any of them, but they're effective first, efficient second. So the art of maximizing the amount of work not required is so essential in what we do to achieve the goal that we have in front of

Rob Durant [00:51:41]:

us. I think Tracy might disagree. Tracy.

Tracy Borreson [00:51:44]:

I wish that Restream had, like, a confetti thing

Mark Entrekin [00:51:47]:

that you can all of my people

Tracy Borreson [00:51:49]:

say stuff because this is, like I I say this all the time. It's like it's like I was having a conversation with my husband yesterday because he was on the phone at, like, 5:30 with his leader who is in EST. So it's like 7:30 PM, and then he was like, oh, yeah. My VP was saying she was doing work at, like, 12 o'clock at night. And I was like, why are people doing these things? It's like we have no desire for personal productivity anymore, and we just, like, do stuff to make it look like we're so important and we're so busy. And, like, most of it, it doesn't do anything. It doesn't contribute to a story. I can tell you that.

Tracy Borreson [00:52:30]:

Unless your story is that I'm only important if I'm busy working all the time. But, like, what story where's the value? Who receives value from this?

Mark Entrekin [00:52:39]:

Well, that's what and and my better half works in the propane industry, and they're taking the tanks to fill fill the tanks. How much of that process are they actually accomplishing something, breaking everything down to that minimum viable product or service so they can then maximize the effectiveness of what they're doing? And a lot of people don't want that accountability, and that's what I mentioned earlier, value accountability and responsibility, which challenges a lot of people beyond their comfort level. Right?

Rob Durant [00:53:08]:

There we go.

Tracy Borreson [00:53:09]:

I just feel like Mark and I are gonna be best friends after today.

Mark Entrekin [00:53:12]:

There you go. Awesome.

Rob Durant [00:53:14]:

Yet another relationship built on the download.

Mark Entrekin [00:53:17]:

We can do this. Mark,

Rob Durant [00:53:19]:

this has been great. We're gonna learn more. How can they get in touch with you?

Mark Entrekin [00:53:24]:

The best way again, that's what my background had. I couldn't get my background up today, but the best way is to get me at mark@markentriken.com as the email, or go to www.marchentrkin.com, or call me at 303 Focused. 303-362-8733. But we all have to be reality focused to reach the goals that we have set in front of us.

Rob Durant [00:53:49]:

Awesome. Excellent. We now have a newsletter. Don't miss an episode. Get episode show highlights. Get beyond the show insights and reminders of upcoming episodes. You can scan the QR code on screen or visit us at digital download dot live forward slash newsletter. On behalf of the panelists, to our guest, Mark, and to our audience, thank you all for being a part of the digital download, and we'll see you next time.

#Agile #ContinuousImprovement #Productivity #SocialSelling #DigitalSelling #SocialEnablemenet #LinkedInLive #Podcast