Agile.FM

De: Joe Krebs
  • Sumário

  • Radio for the Agile Community

    2013-2024
    Exibir mais Exibir menos
Episódios
  • 153: Luke Hohmann
    Jun 25 2024
    Proft Streams BookTranscript:Agile FM radio for the agile community. Today I'm thrilled to have Luke Holman with me in the podcast here of Agile FM and I can't believe After all these episodes I had so far I haven't had you on the show, which is a big miss. You are a renowned expert in agile methodologies an author. And I think a lot of people know you from the innovation games which is a framework for collaborative decision making problem solving.You have experience that dates back way, way back into the 1990s, pre Agile, but also I heard recently that you were involved in the 2003 Agile conference. So yeah, a while back. Welcome to the show, Luke. [00:00:46] Luke Hohmann: Joe, I am so happy to be here. I've known you through the community. We've seen each other at conferences.And so it's a, it's quite an honor to be here. Thank you so much for inviting me to participate. Thanks [00:00:58] Joe Krebs: Yeah, no, absolutely. We could talk about the innovation games and fill an entire show, but today we could, but today we want to talk a little bit about value profit stream, the agile community as often. This is the recordings taking place on the 25th of June, 2024 is a little bit in a turmoil. The Agile community as a whole, there seems to be some different kind of directions people are going, looking at the roles. It's maybe a good time to talk about what value is, how we can present value because at the end of the day is, it's like, how do we sell agility within an organization or for organizations?[00:01:44] Luke Hohmann: I think it'd be a good thing to talk about. There, there's so many aspects of this that are interesting, but let's try a few. And I'll also talk about the rule of self interest in the Agile community. When we talk about value we think about it in terms of our Profit Streams book and our Profit Streams work as What are the set of tangible and intangible benefits that a product or service we use solution as the single term for product and service or any blend thereof.So it's just a little easier because we're here to solve problems for our customers. So we think of both the tangible and intangible benefits. And for the tangible benefits, we help companies create mathematical equations that capture the benefits. And we often work with our clients because technical people are good at being efficient in terms of doing things like saving time.But the reality is most companies don't need to save time. They need to have the time converted into a metric that they can understand for their business purposes. One of the examples we use in our book, and it's been proven in many of our client engagements, Is we were working with a trucking company, and they were going to be buying software that saved their drivers time.So drivers in the trucking industry have to keep detailed logs of their hours of service to make sure they're taking breaks, etc. And this solution enabled the data to be acquired automatically by connecting into the engine bus. And they knew if the truck was on and if it was moving and all that kind of technological internet of things capability that we love.And there's so many things that we can do. So the company that we were working for, and this was Qualcomm had the solution. They went to the trucking organizations and said, Hey, we can save you 20 to 30 minutes a day in driver time. And Joe, we were able to prove this. Absolutely through, the data, like the data was very clear.And the trucking company's executive said we don't really care about that. Because our drivers are union and they are paid for eight hours. So saving me 30 minutes of a driver's time doesn't actually save me money. It doesn't do anything for me. So we had to go back to the drawing board with Qualcomm and find out how to reroute drivers using the new systems so the trucking companies could deliver another package or two in a day because that's how they made money through package delivery.Or the other part of this would be the intangible side and intangible benefits can be quantified on the intangible side for challenging deliveries. We were able to allocate more time in the driver's schedule so that customer satisfaction improved. And as customer satisfaction improved, we would see less churn among customers.Oh, my package was delivered well. I want to use this company again. My, my package was delivered without any breakage. I want to use this company again. So the first step of value is to actually take a step back and try to quantify the tangible and intangible aspects of value. And then I'll just real quickly, I'll finish that off.The second of the determination of value is what we call direct and indirect benefits. A direct benefit is something that you will recognize as a benefit and it materially affects your purchase or use decision. An indirect benefit is something that you recognize, you'll say, yes, the benefit exists, but it doesn't influence you.And I'll give you a kind of a standard example....
    Exibir mais Exibir menos
    38 minutos
  • 152: Lisa Crispin
    May 1 2024
    Transcript: Agile FM radio for the agile community. [00:00:04] Joe Krebs: In today's episode of Agile FM, I have Lisa Crispin with me. She can be reached at very easy to remember lisacrispin. com. Lisa is an author of a total of five books. There's three I want to highlight here or four actually is Obviously, a lot of people have talked in 2009, when the book Agile Testing came out, a practical guide for testers and Agile teams.Then following that more Agile Testing, right? Then I thought it would be most Agile Testing, but it turned into Agile Testing Condensed in 2019 and just very recently a downloadable book, Holistic Testing, a mini book. Welcome to the podcast, Lisa. [00:00:47] Lisa Crispin: Thank you for inviting me. I'm honored to be part of the podcast.You've had so many amazing people on so many episodes. So it's great. [00:00:54] Joe Krebs: Thank you. And now it's one more with you. So thank you for joining. And we will be talking a little bit about a totally different topic than maybe the last 20 episodes I had maybe way back. I did some testing topics, but I cannot recall maybe the last 20 episodes.So we're not about testing a super important topic. I would not consider myself an expert in that. And I don't know of the audience who has been listening to maybe the last 20 episodes are very familiar with agile testing. Maybe everybody has a feeling about, when they hear the word testing, but there is a huge difference between agile testing.And let's say traditional testing methods. If you just want to summarize like very brief, I know a lot of people are familiar with some of those things, but what it is, if somebody says what is agile testing, why was this different to traditional testing methods? [00:01:47] Lisa Crispin: Yeah. I think that there are a couple of big differences.One is that testing this is just a truth and not necessarily something to do with agile, but testing is really just part of software development. So many people think of it as a phase that happens after you write code, but in modern software development we're testing all the time, all the way around that whole DevOps loop, really.And and so the whole team's getting engaged in it through the whole lifecycle and the focus. Is on bug prevention rather than bug detection. Of course, we want to detect the bugs that make it out to production so we can fix them quickly. But really what we want to do is prevent those bugs from happening in the first place.So there are all these great practices that were popularized by that extreme programming and agile, things like test driven development, continuous integration, test automation all the things that go into, the planning. Workshops and things where we talk about our new features and break them into stories and what's going to be valuable to customers, having those early conversations, getting that shared understanding, things like behavior driven development, where we think about what we're going to code before we code it.That's all really different from, I guess I would say a more traditional software development approach where, Oh, we focus on these requirements. The requirements and a lot of people think about testing is just make sure it met the requirements. But there's so much more to that. We've got all these quality attributes, like security and performance and all the things that we also need to test.So it's a huge area, but it's woven into software development, just like coding, just like design, just like architecture, just like monitoring and observability. It's all part of the process. [00:03:31] Joe Krebs: Yeah. It's like a QA baked in, if you want to see it this way. And then also the automation of all that, right?So automating everything you just said is probably also a concern. Not that's necessarily new to agile, but that's a focus as well now I don't know if I don't have necessarily data points around that but I have worked with a lot of Scrum teams and Agile teams in my career.And it seems, if somebody would say what are the challenges within these teams? And one of them is, you can almost always highlight that, and I say almost purposely because there are good exceptions, is to build an increment of work once per sprint. A lot of teams do not accomplish that, and it's often related to testing activities.Why is that, in your opinion, like when we're seeing these teams struggle to put an increment of work out or a piece of the product or whatever you want to call it if you don't use Scrum necessarily, but to build something that could potentially go out. It's the quality standards of going out. What are the struggles out there for teams, especially on the testing side?I see that as you just said, like it's always happening or often happens at the end, rather than in the front. [00:04:46] Lisa Crispin: Yes. Unfortunately, I see, still see a whole lot of scrum teams and other agile teams doing a mini waterfall where they have testers on the cross functional ...
    Exibir mais Exibir menos
    31 minutos
  • 151: Maureen McCarthy and Zelle Nelson
    Apr 22 2024
    Transcript: Agile F M radio for the agile community. [00:00:04] Joe Krebs: Thank you for tuning into another episode here of Agile FM. Today I have two guests with me. We are a trio today that is Maureen McCarthy and Zelle Nelson are with me. They both are we're going to go really deep on this the creators of the method that's called the Blueprint of We and they can be reached at collaborativeawareness. com. Welcome to the podcast, Maureen and Zelle. [00:00:28] Maureen McCarthy: I am so thrilled for this conversation, Joe, because. The weaving between Agile and the work we do in the world is brilliant. And I love having the conversation about how that goes on. So [00:00:39] Zelle Nelson: really happy to be here. [00:00:40] Maureen McCarthy: Yeah. Thanks. [00:00:41] Joe Krebs: Awesome. Yeah, we will be talking a little bit about that blueprint of we, but before we do that just to set the stage a little bit with everyone, why the blueprint of we exist, why your work exists.There is a very sad history to this, and that is that Maureen, you found out that you have a rare genetic lung disease, and you are. Operating on 10% lung capacity. Is that correct? [00:01:11] Maureen McCarthy: That is true. I've been on oxygen for 20 years, but nobody lives as long as I have. So it's a, it's very rare. Most people are dead.Within 10 years I've had it 35 . [00:01:21] Maureen McCarthy: So I've had since I was very young. But it's not a sad story. It's actually a very creative story. It's not, I don't, there's lots of crazy stuff that goes on with it, but I don't feel sad about it. We've done so many, we've made the stress of what.A health challenge can be into a creative process of How do you thrive even when stuff is going on that's nuts. [00:01:43] Joe Krebs: Yeah the reason why we connect a little bit the blueprint of we the work you guys are doing and facilitation collaboration is directly tied to this to the lung disease. Can you guys elaborate a little bit on.How this all started for you guys and how you are, obviously your behavior changed as a result of that diagnosis [00:02:08] Maureen McCarthy: we actually met the year my doctors told me that I would die. So it was my 10 year mark of when most people are dead and meeting somebody. We both had our own individual businesses at that point, but meeting somebody the year you're supposed to die, you don't measure anything up against forever.You have to look at what's here right now and decide what you want to do with it. And we realized like the normal path when you meet someone is, do you want to date and get engaged and get married and have a white picket fence? Like you actually have those things that just project in your mind, because that's expected, to at least ask those questions. [00:02:44] Zelle Nelson: There was nothing for us to pull off the shelf to say, this is how you do it. [00:02:48] Maureen McCarthy: Yeah. [00:02:49] Zelle Nelson: So we had to design it for ourselves [00:02:51] Maureen McCarthy: and we created this. Document this relationship design document. We realize we've got to design something that's so specific to us and there's things that we want to No one understand about ourselves, about each other, but most specifically about who we are together.If this isn't what doing what you normally do when you become a couple, what the heck is it? So that design process we wrote down, we're like, let's do a design process, a design document, let's make it iterative and changeable and. Upgraded over time to, to show us who we are when we learn more about ourselves, about another, when we go through the chaos of in and out of the hospital and losing more lung capacity and massive levels of pain and just crazy things.You've got to be agile. You literally have to be agile. And without the design document, I think we could have gotten lost. In a path that can be very chaotic, especially because lots of people around us got worried. It made me understand the difference between worry and care. Like when people worry for me, all my pain gets worse.It's harder to breathe when people care about me. It's two different ways we're using our neurocircuitry, right? And care is a way to support other people. Worry is a way to add more stress and fear and the weightiness of all that. And when you've got 10 percent lung capacity. You feel weightiness unlike other people.Yeah, this is, I'm like a little like a little experiment of my own body of what it means to be like collaborative and connected, because everything that's going on in my body, we use as a way to be part of the design. Like this, there's chaos going on in here. How does that mirror the chaos of the world and how do we design healthy relationships and healthy interactions based on, what could be considered chaos?[00:04:40] Joe Krebs: Yeah, so this blueprint you guys, we're going to go a little bit deeper here. It's really something you build, it's a process. It's a relationship design process used to ...
    Exibir mais Exibir menos
    30 minutos

O que os ouvintes dizem sobre Agile.FM

Nota média dos ouvintes. Apenas ouvintes que tiverem escutado o título podem escrever avaliações.

Avaliações - Selecione as abas abaixo para mudar a fonte das avaliações.