Podcasts about gojko

BONUS: Gojko Adzic on Optimizing Products for Long-Tail Users (Agile Online Summit 2024 Replay) In this BONUS episode, we revisit Gojko Adzic's insightful interview at the Agile Online Summit 2024. Gojko, an award-winning author and software expert, unpacks the principles behind his latest book, Lizard Optimization, offering a fresh perspective on improving product usability by addressing the needs of long-tail users. From learning from unexpected user behaviors to refining products with a systematic approach, this episode is filled with practical tips for product teams and Agile practitioners. What is Lizard Optimization? Drawing from his experiences as a product developer, Gojko introduces the idea of Lizard Optimization. He discusses how observing unexpected user behaviors led him to refine his SaaS tools like Narakeet and MindMup. By focusing on usability challenges and unusual patterns, he has turned serendipity into actionable insights. “Users aren't stupid—they're just finding creative ways to get value from your product. Listen to them.” Gojko explains the inspiration behind the metaphor of the “Lizardman constant,” a concept from a Scott Alexander blog post. He describes how this principle applies to product optimization: understanding and addressing the 4% of surprising, unexplainable behaviors can uncover opportunities for innovation. “The job isn't to judge users—it's to explore why they're doing what they're doing and how we can help them succeed.” The High-Level Process of Lizard Optimization Gojko outlines the systematic process described in his book to leverage unexpected user behavior: Observe Misuse: Identify how users deviate from expected patterns. Extract Insights: Focus on one unexpected behavior as a signal. Remove Obstacles: Help users achieve their goals more easily. Monitor Impacts: Detect and adjust for unintended consequences. “Start monitoring for the predictable but unexpected—those hidden gems can unlock your next big feature.” Practical Advice for Product Teams For teams ready to apply these concepts, Gojko emphasizes the importance of expanding observability tools to include product metrics and not just technical ones. He shares how tracking unpredictable user actions can inspire impactful changes. “About a third of what we do delivers value—focus on finding where unexpected value lies.” Recommended Resources To dive deeper into these ideas, Gojko recommends: Trustworthy Online Controlled Experiments by Ron Kohavi Evidence Guided by Tim Herbig LizardOptimization.org “Experimentation and evidence-based decision-making are the keys to building better products.” Closing Thoughts: “Look for the Unexpected” Gojko's parting advice for Agile practitioners is simple yet powerful: Look for the unexpected. By embracing surprises in user behavior, teams can transform minor inconveniences into major opportunities for growth. “The unexpected is where innovation begins.” About Gojko Adzic Gojko Adzic is an award-winning author, speaker, and product creator. His books, including Lizard Optimization, Impact Mapping, and Specification by Example, have become essential reads for Agile practitioners and product teams worldwide. Gojko is a 2019 AWS Serverless Hero, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. He has also co-founded several successful SaaS tools, including Narakeet, MindMup, and Votito. You can link with Gojko Adzic on LinkedIn.

Gojko Adzic - Lizard OptimizationLook who's back! Gojko Adzic will present us his new book Lizard Optimization: Unlock product growth by engaging long-tail users.As we read on the back cover: "Lizard Optimization is a technique for designing product development experiments by engaging long-tail users that seem to follow some unexplainable "lizard" logic. It can help you understand your audience better and improve your products. The method is based on the author's experience managing an online software product that grew explosively from November 2021 to November 2022. The key user metric, tracking when people are getting value from the product, increased by more than 500 times in those 12 months (times, not percent). This happened after a period of unremarkable growth and a slow decline. Looking back, the key factor in reversing the decline and unlocking exponential growth was a counter-intuitive approach to engaging users. This book is a summary of the key lessons from that crazy growth phase, synthesized into a simple process that you can apply to improve your products, and help you unlock growth, reduce churn and increase revenue."And as usual - plenty of space for your questions! 

Gojko Adzic - Lizard OptimizationLook who's back! Gojko Adzic will present us his new book Lizard Optimization: Unlock product growth by engaging long-tail users.As we read on the back cover: "Lizard Optimization is a technique for designing product development experiments by engaging long-tail users that seem to follow some unexplainable "lizard" logic. It can help you understand your audience better and improve your products. The method is based on the author's experience managing an online software product that grew explosively from November 2021 to November 2022. The key user metric, tracking when people are getting value from the product, increased by more than 500 times in those 12 months (times, not percent). This happened after a period of unremarkable growth and a slow decline. Looking back, the key factor in reversing the decline and unlocking exponential growth was a counter-intuitive approach to engaging users. This book is a summary of the key lessons from that crazy growth phase, synthesized into a simple process that you can apply to improve your products, and help you unlock growth, reduce churn and increase revenue."And as usual - plenty of space for your questions! 

In the latest episode of Le Podcast on Emerging Leadership, I welcome back Gojko Adzic, renowned software development expert and author of Lizard Optimization. Gojko dives into an engaging discussion about his book, offering practical ways to identify hidden opportunities by paying close attention to unexpected user behavior—what he calls "lizard optimization." Find the key learnings, the transcript and more in the companion blog post: https://alexis.monville.com/en/2024/10/29/optimizing-for-the-unexpected-insights-from-gojko-adzic-on-lizard-optimization/

This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences. In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Gojko Adzic about his work in software development, product management, and value creation. Gojko discusses his experiences in building and improving products, the importance of measuring user behavior changes, and the concept of "lizard optimization" - improving products by addressing unexpected user behaviors. Read a transcript of this interview: https://bit.ly/485EukY Subscribe to the Software Architects' Newsletter for your monthly guide to the essential news and experience from industry peers on emerging patterns and technologies: https://www.infoq.com/software-architects-newsletter Upcoming Events: QCon San Francisco (November 18-22, 2024) Get practical inspiration and best practices on emerging software trends directly from senior software developers at early adopter companies. https://qconsf.com/ QCon London (April 7-9, 2025) Discover new ideas and insights from senior practitioners driving change and innovation in software development. https://qconlondon.com/ Save the date: InfoQ Dev Summit Boston (June 9-10, 2025) Actionable insights on today's critical dev priorities. The InfoQ Podcasts: Weekly inspiration to drive innovation and build great teams from senior software leaders. Listen to all our podcasts and read interview transcripts: - The InfoQ Podcast https://www.infoq.com/podcasts/ - Engineering Culture Podcast by InfoQ https://www.infoq.com/podcasts/#engineering_culture - Generally AI: https://www.infoq.com/generally-ai-podcast/ Follow InfoQ: - Mastodon: https://techhub.social/@infoq - Twitter: twitter.com/InfoQ - LinkedIn: www.linkedin.com/company/infoq - Facebook: bit.ly/2jmlyG8 - Instagram: @infoqdotcom - Youtube: www.youtube.com/infoq Write for InfoQ: Learn and share the changes and innovations in professional software development. - Join a community of experts. - Increase your visibility. - Grow your career. https://www.infoq.com/write-for-infoq

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubRead the full transcription of the interview hereGojko Adzic - Software Delivery Consultant & Author of "Lizard Optimization" and many more BooksDave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.RESOURCESGojkohttps://twitter.com/gojkoadzichttps://www.linkedin.com/in/gojkohttps://github.com/gojkohttps://gojko.netDavehttps://twitter.com/davefarley77https://linkedin.com/in/dave-farley-a67927http://www.continuous-delivery.co.ukhttp://www.davefarley.netDESCRIPTIONDave Farley and Gojko Adzic discuss Gojko's latest book “Llizard Optimization”, which involves identifying and leveraging unconventional uses and misuses of products to improve them for all users. Gojko shares insights and examples from his experiences with Narakeet and MindMup, highlighting how addressing the needs of outlier users led to significant product enhancements and growth.They also touch on broader themes of user retention, the joy of building and solving problems, and the balance between solo work and collaborative efforts in software development and writing.RECOMMENDED BOOKSGojko Adzic • Lizard OptimizationGojko Adzic • Impact MappingAdzic, Evans & Roden • Fifty Quick Ideas To Improve Your TestsAdzic, Evans & Korac • Fifty Quick Ideas to Improve Your User StoriesAdzic & Korac • Humans vs ComputersGojko Adzic • Specification by ExampleAdzic, Marcetic & Bisset • Bridging the Communication GapAdzic & Korac • Running ServerlessKat Holmes • MismatchDavid Farley • Modern Software EngineeringDave Farley • Continuous Delivery PipelinesDave Farley & Jez Humble • Continuous DeliveryTwitterInstagramLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

What do lizards have to do with product growth? In this episode, Gojko Adzic reveals how unusual user behaviors can unlock massive opportunities for product innovation. Discover the four steps to mastering "Lizard Optimization" and learn how you can turn strange user actions into game-changing insights. Overview In this episode of the Agile Mentors Podcast, host Brian Milner chats with Gojko Adzic about his new book, Lizard Optimization. Gojko explains the concept of finding product growth signals in strange user behaviors, sharing examples where unexpected user actions led to product breakthroughs. He outlines a four-step process for optimizing products by learning, zeroing in, removing obstacles, and double-checking. Gojko also discusses helpful tools like session recorders and observability tools that can enhance product development by uncovering and addressing unique user behaviors. References and resources mentioned in the show: Gojko Adzic 50% OFF Lizard Optimization by Gojko Adzic Mismatch: How Inclusion Shapes Design by Kat Holmes Trustworthy Online Experiments by Ron Kohavi Advanced Certified Scrum Product Owner® Subscribe to the Agile Mentors Podcast Join the Agile Mentors Community Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Gojko Adzic is an award-winning software consultant and author, specializing in agile and lean quality improvement, with expertise in impact mapping, agile testing, and behavior-driven development. A frequent speaker at global software conferences, Gojko is also a co-creator of MindMup and Narakeet, and has helped companies worldwide enhance their software delivery, from large financial institutions to innovative startups. Auto-generated Transcript: Brian (00:00) Welcome in Agile Mentors. We're back for another episode of the Agile Mentors podcast. I'm with you as always, Brian Milner. And today, very special guest we have with us. have Mr. Goiko Atshich with us. I hope I said that correctly. Did I say it correctly? Close enough. Okay. Well, welcome in, Goiko. Glad to have you here. Gojko (00:15) Close enough, close enough. Brian (00:21) Very, very, very happy to have Goiko with us. If you're not familiar with Goiko's name, you probably are familiar with some of his work. One of the things I was telling him that we teach in our advanced product owner class every time is impact mapping, which is a tool that Goiko has written about and kind of come up with on his own as well. Gojko (00:21) Thank you very much for inviting me. Brian (00:47) But today we're having him on because he has a new book coming out called Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And I really wanted to talk to him about that and help him explain, have him explain to us a little bit about this idea, this new concept that his new book is about. So, Goiko, let's talk about it. Lizard Optimization, in a nutshell, what do you mean by that? What is it? Gojko (01:14) We're going to jump into that, but I just need to correct one of the things you said. I think it's very, very important. You said I came up with impact mapping and I didn't. I just wrote a popular book about that. And it's very important to credit people who actually came up with that. It's kind of the in -use design agency in Sweden. And I think, you know, they should get the credit for it. I literally just wrote a popular book. Brian (01:19) Okay. Gotcha. Gotcha, gotcha. Apologies for that incorrect. Thank you for making that correction. So lizard optimization. Gojko (01:44) So, lizard optimization. Good. So, lizard optimization is an idea to find signals for product ideas and product development ideas in strange user behaviors. When you meet somebody who does something you completely do not understand, why on earth somebody would do something like that? Brian (02:03) Okay. Gojko (02:11) and it looks like it's not done by humans, it looks like it's done by somebody who follows their own lizard logic, using stuff like that as signals to improve our products. Not just for lizards, but for everybody. So the idea came from a very explosive growth phase for one of the products I'm working on, where it... had lots of people doing crazy things I could never figure out why they were doing it. For example, one of the things the tool does is it helps people create videos from PowerPoints. You put some kind of your voiceover in the speaker notes, the tool creates a video by using text to speech engines to create voiceover from the speaker notes, aligns everything and it's all kind of for you. People kept creating blank videos and paying me for this. I was thinking about why on earth would somebody be creating blank videos and it must be a bug and if it's a bug then they want their money back and they'll complain. So I chased up a few of these people and I tried to kind of understand what's going on because I originally thought we have a bug in the development pipeline for the videos. So... I started asking like, you know, I'm using some, I don't know, Google slides or, you know, keynote or whatever to produce PowerPoints. Maybe there's a bug how we read that. And the person, no, no, we, know, official Microsoft PowerPoint. They said, well, can you please open the PowerPoint you uploaded? Do you see anything on the slides when you open it? And the person, no, it's blank. Right? Okay, so it's blank for you as well. I said, yeah. So. Brian (03:48) Yeah. Gojko (03:54) What's going on? so what I've done is through UX interviews and iterating with users and research, we've made it very, very easy to do advanced configuration on text -to -speech. And it was so much easier than the alternative things that people were creating blank PowerPoints just to use the text -to -speech engines so they can then extract the audio track from it. Brian (03:54) Yeah, why? Gojko (04:23) and then use that and it was this whole mess of obstacles I was putting in front of people to get the good audio. It wasn't the original intention of the tool. It wasn't the original value, but people were getting unintended value from it. And then I ended up building just a very simple screen for people to upload the Word document instead of PowerPoints. And it was much faster for users to do that. A month later, there was many audio files being built as videos. Two months later, audio... production overtook video production. then at the moment, people are building many, many more audio files than video files on the platform. So it was an incredible growth because of this kind of crazy insight of what people were doing. kind of usually, at least kind of in the products I worked on before, when you have somebody abusing the product, product management fight against it. There's a wonderful story about this in... Founders at work a book by Jessica Livingston and she talks about this kind of group of super smart people in late 90s who Came up with a very very efficient Cryptography algorithm and a way to compute the cryptography so they can run it on low -power devices like Paul pilots Paul pilots were you know like mobile phones, but in late 90s and Then they had to figure out, how do we monetize this? Why would anybody want to do this? So they came up with the idea to do money transfer pumping, Palm pilots, you know, why not? And kind of the built a website. This was the late nineties as a way of just demoing this software to people who didn't have a Palm pilot device next to them. The idea was that you'd kind of see it on the website, learn about it, then maybe download the Palm pilot app and use it in anger. People kept just using the website, they're not downloading the Palm Pilot app. So the product management really wasn't happy. And they were trying to push people from the website to the Palm Pilot app. were trying to, they were fighting against people using this for money transfer on the web and even prohibiting them from using the logo and advertising it. They had this whole thing where nobody could explain why users were using the website because it was a demo thing. It was not finished. It was not sexy. It was just silly. And Jessica kind of talks to one of these people who insists that it was totally inexplicable. Nobody could understand it. But then a bit later, they realized that the website had one and half million users and that the Pongpilot app had 12 ,000 users. So they kind of decided, well, that's where the product is really. And that's like today, people know them as PayPal. They're one of the biggest payment processes in the world because kind of, you know, they realized this is where the product is going. And I think in many, many companies, people Brian (07:03) Ha ha. Gojko (07:18) stumble upon these things as happy accidents. And I think there's a lot more to it. We can deliberately optimize products by looking for unintended usage and not fighting it, just not fighting it. just understand this is what people are getting as value. And I think for me as a solo product founder and developer and product manager on it, One of the really interesting things is when you have somebody engaging with your product in an unexpected way, most of the difficult work for that user is already done. That person knows about you, they're on your website or they're using your product, the marketing and acquisition work is done. But something's preventing them from achieving their goals or they're achieving some value that you did not really know that they're going to achieve. you know, that's something the product can do to help them and remove these obstacles to success. So that's kind of what lizard optimization is making this process more systematic rather than relying on happy accidents. And by making it more systematic, then we can help product management not fight it and skip this whole phase of trying to fight against our users and claim that users are stupid or non -technical or... They don't understand the product, but they're trying to figure out, well, that's what the real goals are. And then following that. Brian (08:47) That's awesome. So the pivot, right? The pivot from here's what we thought our problem was we were solving to now here's what we're actually solving and we should organize around this actual problem, right? Gojko (09:02) or here's what we're going to solve additionally. This is the problem we've solved, but hey, there's this problem as well. And then the product can grow by solving multiple problems for people and solving related problems and solving it for different groups of people, for example. And that's the really interesting thing because I think if you have a product that's already doing something well for your users and a subset of them are misusing it in some way, then kind of... Brian (09:04) Yeah. Gojko (09:30) The product might already be optimized for the majority of users, but there might be a new market somewhere else. So there might be a different market where we can help kind of a different group of users and then the product can grow. Brian (09:43) Yeah, I like to focus on the user. There's an exercise that we'll do in one of our product owner classes where we have a fake product that is a smart refrigerator. And one of the exercises we try to get them to brainstorm the different kinds of users that they might have for it. And one of the things that always comes out in that class is as they're going through and trying to describe the types of users, they inevitably hit to this crossroads where they start to decide Well, yes, we're thinking of this as a home product, something for people to use in their homes. But then the idea crosses their mind, well, what about commercial kitchens? What about people who might use this in another setting? And it's always an interesting conversation to say, well, now you've got a strategic choice to make, because you can target both. You can target one. You can say, we're ignoring the other and we're only going in this direction. So to me, I think that's kind of one of the interesting crossroad points is to say, how do I know when it's time to not just say, great, we have this other customer segment that we didn't know about, but actually we should start to pivot towards that customer segment and start to really target them. Gojko (11:03) Yeah, think that's a fundamental question of product development, isn't it? Do you keep true to your vision even if it's not coming out or if something else is there that's kind more important than I think? For me, there's a couple of aspects to that. One is, laser focus is really important to launch a product. You can't launch a product by targeting... the whole market and targeting a niche type, figuring out, you know, user personas, figuring out like really, really, this is the product who we think the product, this is the group who we think the product is for and giving them a hundred percent of what they need is much better than giving 2 % to everybody because then the product is irrelevant. But then to grow the product, we need to kind of grow the user base as well. And I think one of the things that... is interesting to look at and this comes from a book called Lean Analytics. It's one of my kind of favorite product management books is to look at the frequency and urgency of usage. If you have a group that's kind of using your product, a subgroup that's using your product very frequently compared to everybody else, that might be kind of the place where you want to go. The more frequently, the more urgently people reach for your product when they have this problem. the more likely they are going to be a good market for it. with kind of another product that I've launched in 2013, we originally thought it's going to be a product for professional users. And we aimed at the professional users. And then we found that a subcategory that we didn't really expect, were kind of teachers and children in schools. we're using it a lot more frequently than professional users. And then we started simplifying the user interface significantly so that it can be used by children. And it's a very, very popular tool in schools now. We are not fighting against other professional tools. We were kind of really one of the first in the education market there. And it's still a very popular tool in the education market because we figured a subgroup that's using it very frequently. Brian (13:14) Hmm. Yeah, that's awesome. How do you know when, you know, what kind of threshold do you look for to determine that, this is, because, you know, in your book, you're talking about, you know, behaviors that are not normal, right? People using your product in a way that you didn't anticipate. And what kind of threshold do you look for to that says, hey, it's worth investigating this? You know, I've got this percentage or this number of people who are using it in this strange way. At what point do you chase that down? Gojko (13:49) I think it's wrong to look at the percentages there. I think it's wrong to look at the percentages because then you get into the game of trying to justify economically helping 0 .1 % of the users. And that's never going to happen because what I like about this is an idea from Microsoft's Inclusive Design and the work of Kat Holmes who wrote a book called Mismatch on Brian (13:52) Okay. Gojko (14:17) assistive technologies and inclusive design for disabled people. And she talks about how it's never ever ever going to be economically justified to optimize a product to help certain disabilities because there's just not enough of them. And there's a lovely example from Microsoft where, Microsoft Inclusive Design Handbook where they talk about three types of, Brian (14:34) Yeah. Gojko (14:44) disabilities, one are permanent. So you have like people without an arm or something like that. And I'm going to kind of throw some numbers out now, order of magnitude stuff. I have these details in the book and there's kind of the micro -inclusive design handbook. Let's say at the moment, the 16 ,000 people in the U .S. without one arm or with a disabled arm. And then you have these kind of situational disabilities where because of an occupation like you have a bartender who needs to carry something all the time or a worker who does it, one arm is not available and they only have one arm to work on and this temporary like a mother carrying a child or something like that. So the other two groups are order of magnitude 20 -30 million. We're not, by making the software work well with one hand, we're not helping 16 ,000 people, we are helping 50 million people. But you don't know that you're helping 50 million people if you're just thinking about like 16 ,000. I think they have this kind of, one of the key ideas of inclusive design is solve for one, kind of help, design for one, but solve for many. So we are actually helping many, many people there. So think when you figure out that somebody is doing something really strange with your product, you're not helping just that one person. Brian (15:45) Right, right. Hmm. Gojko (16:13) you're helping a whole class of your users by making the software better, removing the obstacles to success. this is where I, you know, going back to the PowerPoint thing I mentioned, once we started removing obstacles for people to build the audios quickly, lots of other people started using the product and people started using the product in a different way. And I think this is a lovely example of what Bruce Torazzini talks about is the complexity paradox because He's a famous UX designer and he talks about how once you give people a product, their behavior changes as a result of having the product. So the UX research we've done before there is a product or there is a feature is not completely relevant, but it's a changed context because he talks about people have a certain amount of time to do a task. And then when they have a tool to complete the task faster, they can take on a more complicated task or they can take on an additional task or do something else. I think removing obstacles to use a success is really important. Not because we're helping 0 .1 % of people who we don't understand, but because we can then improve the product for everybody. And I think that's kind of the magic of lizard optimization in a sense, where if we find these things where somebody's really getting stuck. but if we help them not get stuck, then other people will use the product in a much better way. And I think this is, know, the name lizard optimization comes from this article by Scott Alexander, who talks about the lizard man's constant in research. And the article talks about his experiences with a survey that combined some demographic and psychological data. So they were looking at where you live and what your nationality is and what gender you are and then how you respond to certain psychological questions. he said, like there's about 4 % of the answers they could not account for. And one person wrote American is gender. Several people listed Martian as nationality and things like that. some of these, he says some of these things will be people who didn't really understand the question. they were distracted, they were doing something else, or they understood the question but they filled in the wrong box because, know, the thick thumbs and small screens, or they were kind of malicious and just, you know, wanted to see what happens. when you kind of add these people together, they're not an insignificant group. kind of, he says 4%. And if... we can help these people, at least some of these people, and say reduce churn by 1%. That can compound growth. Reducing churn, keeping people around for longer is an incredible way to kind of unlock growth. going back to what we were talking about, some people might be getting stuck because they don't understand the instructions. Some people might be getting stuck because they're using the product in a way you didn't expect. And some people might just like not have the mental capacity to use it the way you expected them to be used. But if we can help these people along, then normal users can use it much, easier. And you mentioned a smart fridge. I still remember there was this one wonderful bug report we had for my other product, which is a collaboration tool. we had a bug report a while ago. that the software doesn't work when it's loaded on a fridge. And it's like, well, it was never intended to be loaded on a fridge. I have no idea how you loaded it on a fridge. It's a mind mapping diagramming tool. It's intended to be used on large screens. Where does a fridge come in? And then we started talking to this person. This was before the whole kind of COVID and work from home disaster. The user was a busy mother and she was kind of trying to collaborate with her colleagues while making breakfast. breakfast for kids and kind of running around the kitchen she wasn't able to kind of pay attention to the laptop or a phone but her fridge had a screen so she loaded the software on the fridge and was able to kind of pay attention to collaboration there and you know we of course didn't optimize the software to run on fridges that's ridiculous but we realized that some people will be using it without a keyboard and without a mouse and then we kind of restructured the toolbar, we made it so that you can use it on devices that don't have a keyboard and then the whole tablet thing exploded and now you get completely different users that don't have keyboards and things like that. I think that's where I think is looking at percentages is a losing game because then you start saying, but 0 .1 % of people use this. But yeah, I think lizard optimization is about using these signals to improve the products for everybody. Brian (21:30) That's a great example. I love that example because you're absolutely right. You're not trying to necessarily solve that one problem because you don't anticipate there's going to be a lot of people who are going to want to run that software on a fridge. However, the takeaway you had from that of, we can do this for people who don't have a keyboard or a mouse. There's another way that they might operate this that could apply to lots of different devices and lots of different scenarios. Now we're talking about a much bigger audience. Now we're talking about opening this up to larger segments of the population. I love that. I think that's a great example. I know you talk about that there's kind of a process for this. Help us understand. You don't have to give away the whole candy story here from the book, but help us kind of understand in broad, terms what kind of process people follow to try to chase these things down. Gojko (22:26) So there's like a four step process that's crystallized for me. And the book is kind of more as a, like a proposal or a process. It's something that works for me and I'm hoping that other people will try it out like that. So it might not necessarily stay like that in a few years if we talk again. And I've narrowed it down to four steps and kind of the four steps start with letters L, Z, R and D. Lizard. And it's kind of so learn how people are misusing your products, zero in on one area, on one behavior change you want to improve, then remove obstacles to use a success and then double check that what you've done actually created the impact you expected to make. I think kind of when we look at people who follow their own logic or people who follow some lizard logic you don't really understand, by definition they're doing something strange. your idea of helping them might not necessarily be effective or it might not go all the way or it might. So double checking at the end that people are actually now doing what you expect them to do or doing something better is really, really, really important. And then using signals from that to improve the kind of feedback loop is critical. I had this one case where people were getting stuck on a payment format entering tax details and The form was reasonably well explained. There was an example in the forum how to enter your tax ID and people were constantly getting stuck. A small percentage of people was getting stuck on it. However, I don't want to lose a small percentage of people that want to pay me on the payment form. So I thought, well, how about if I remove that field from there? I speed it up for everybody and then I can guide them later into entering the tax details to generate an invoice. I thought that was a brilliant idea. tested it with a few users. Everybody loved it, so I released it. And then a week later, I realized that, yes, I've sold it for the people that were getting confused, but I've ended up confusing a totally different group of people that expects the tax fields there. So the net effect was negative. then I went back to the original form. so there's lots of these things where people don't necessarily behave the way you think they will. Brian (24:38) Hahaha. Gojko (24:48) Ron Kohavi has a wonderful book about that called Trustworthy Online Experiments. And he has data from Slack, from Microsoft, from Booking .com and... The numbers are depressive. on one hand, the numbers range from 10 to 30, 40 % success rate for people's ideas. And if leading companies like that do things that don't pan out two thirds of the time, then we have to be honest building our products and say, well, maybe this idea is going to work out, maybe not. Brian (25:03) Hahaha. Wow. Gojko (25:30) the more experimental the population is, the more risky that is. think monitoring and capturing weird user behaviors, capturing errors helps you understand that people are getting stuck. as you said, you don't want to follow everybody. There's going to be a lot of noise there. We need to extract signals from the noise. That's what the second step is about, focusing on one specific thing we want to improve. Then, try to remove obstacles and then double -checking that we've actually removed them. That's the four steps. And there's like a shorter version of all the four steps. It's easier to remember. It's listen alert, zooming, rescue them, and then double check at the end. that's again, LZRD. Brian (26:13) That's awesome. Yeah, I love the process and I love the kind of steps there. Are there tools that you recommend for this that are easier to try to determine these things or chase them down or are there tools that you find are more helpful? Gojko (26:32) So there's lots of tools today for things like A -B testing and looking at experiments and things that are very helpful to do this scale. And it's kind of especially useful for the last step. In terms of kind of focusing and things like that, the five stages of growth from the linear analytics are a good tool. Impact mapping is a good tool. Kind of any focusing product management technique that says, well, these are the business goals we're working on now, or these are the kind of user goals we're working on now. out of, know, 50 lizards we found last week, these three lizards seem to be kind of in that area. And for the first step, spotting when people are getting stuck, there's a bunch of tools that are interesting, like session recorders for web products. There's one from Microsoft called Clarity that's free. There's another called Full Story that's quite expensive. There's a couple of open source one, one is packaged within Matomo analytics application. There's a bunch of these other things. Any kind of observability or monitoring tool is also very useful for this because we can spot when people are getting stuck. One of the things I found particularly helpful is logging all user errors. When a user does something to cause an error condition in a product, the product of course tells them like, know, an error happened. But then... logging it and analyzing that information in the back is really critical. for something like that, people sometimes use web analytics tools or any kind of product analytics. I think what's going to be interesting in the next couple of years, and I think if people start doing this more, is we'll see. more like these technical exception analytics tracking tools mixed with this because most of the product analytics are showing people what they expect to see, not what they don't expect to see. And I'll just give you an example of this way. was really helpful. So I've mentioned the screen where people can upload the Word documents. Occasionally people would select weird file types. So they'll select images, they'll select, I don't know, what else. Brian (28:31) Yeah. Gojko (28:49) Sometimes I guess that's a result of, know, a fat finger press or somebody not selecting the right thing. I have a not insignificant percentage of users every day that try to upload Android package files into a text -to -speech reader. Android package files and application files, I don't know what the right way is to read out an Android application. My best guess is people are doing that. as a, you know, these things where you drop a USB in front of an office and somebody kind of mistakenly plugs it in. So maybe they're hoping that I'll know the Android application on my phone just because they've uploaded it. I don't know, but a small percentage of users was trying to upload files that had SRT and VTT extensions, which are subtitle files. And they were not supported, but Brian (29:31) Yeah. Gojko (29:45) I kept getting information that people are uploading those types of files. And then I said, well, this is interesting because it's a text to speech system. People are uploading subtitle files, there's text in, so why don't I just ignore the timestamps and read the text? I can do that. And I started supporting that. And then some people started complaining that, well, the voice is reading it slower than the subtitles. I said, well, yes, because... Brian (30:11) Ha Gojko (30:12) You know, you're uploading subtitles that were read by an actor in a movie. This is a voice that's reading it at their speed. And then we started talking and it turns out that these people were doing it for corporate educational videos where they have a video in English, they need it in French, German, Spanish and all the else, but they don't want to kind of re -edit the video. They just want an alternate audio track. Okay, I mean, I have the timestamps, we can speed up or slow down the audio, it's not a big deal. And we've done that and this was one of the most profitable features ever. Like a very small percentage of the users need it, but those that need it produce hundreds of thousands of audio files because they translate the corporate training videos. And now, you know, we're getting into that numbers game. If I said, you know, there's like 0 .1 % of people are uploading subtitle files. Brian (30:58) Yeah. Gojko (31:07) then it doesn't matter. if we start thinking about, this is potentially interesting use case, it creates growth on its own because then people find you. And I think my product was the first that was actually doing synchronous subtitles. Competitors are doing it now as well. But it opened the massive, massive market for us. And people, you know, I got there by monitoring user errors, by, you know, the fact that somebody uploaded a file that had an unsupported extension. That was our insight. Brian (31:38) Wow, that's really cool. That's a great story. This is fascinating stuff. And it makes me want to dive deeper into the book and read through it again. But I really appreciate you coming on and sharing this with us, Goiko. This is good stuff. Again, the book is called, Lizard Optimization, Unlock Product Growth by Engaging Long Tail Users. And if I'm right, we talked about this a little bit before. We're going to offer a discount to to the listeners, Gojko (32:07) Yes, we will give you a listen as a 50 % discount on the ebook. the ebook is available from Lean Pub. If you get it from the discount URL that I'll give you, then you'll get a 50 % discount immediately. Brian (32:24) Awesome. So we'll put that in our show notes. If you're interested in that, you can find the show notes. That's a great deal, 50 % off the book and it's good stuff. well, I just, I can't thank you enough. Thanks for making time and coming on and talking this through your book. Gojko (32:40) Thank you, it was lovely to chat to you.

Today, we have a special guest, Gojko Adzic, who introduces his new book "Lizard Optimization." Check out BrowserStack Test Management testguild.me/browserstack Join us as Gojko walks us through the significant value testers can bring to organizations beyond merely reporting bugs and evaluating product readiness. We'll delve into his rich experiences with user behavior at scale and the formidable challenges he's faced while offering practical strategies to unlock remarkable product growth. In this episode, we discuss Gojko's innovative four-step lizard optimization method and the hidden power of edge cases. Gojko emphasizes testers' fundamental role in product innovation, mainly through experimentation and user behavior analysis. We'll also touch on the balance between addressing accessibility needs and identifying obstacles in user workflows to enhance usability for everyone. Listen in as Joe and Gojko explore the insightful intersection of user expectations and software design, leveraging customer support data for product improvements and the transformative potential of monitoring production environments. Whether you're a software tester, developer, or product manager, this episode is packed with actionable insights and thought-provoking perspectives that promise to elevate your approach to software development and user engagement. Don't miss out!

SummaryIn this episode, Goiko shares his experiences and insights on visualizing specifications, writing Specification by Example, and solving communication problems in software development. He discusses the challenges and patterns in the adoption of Spec by Example and the importance of identifying bottlenecks and visualizing problems. Goiko also talks about causing organizational change and the evolution of software development solutions. He concludes by discussing the promise and reality of no-code tools and sharing his recent work and projects. The conversation explores various themes related to software development and its impact on organizations and society. It discusses the power of expressing human knowledge in software and the role of visualization tools in increasing shared understanding. The shift from specialists to generalists in the software industry is examined, as well as the potential for smaller organizations and general-purpose work. The conversation also delves into the role of AI in minimizing political games in organizations and the responsibility of software professionals in creating good software. The need for spending more time on edge cases and negative use cases is highlighted, along with the societal impact of bad software and the potential for IT to become a profession. The conservation and shifting of complexity in software development is explored, and the conversation concludes with a discussion on the impact of shoddy software on people's lives.TakeawaysVisualizing specifications can help improve understanding and reduce rework in software development.The adoption of Spec by Example and other agile practices can be hindered by organizational politics and resistance to change.Identifying bottlenecks and visualizing problems can lead to effective solutions and improvements in software development processes.No-code tools have the potential to democratize software development and empower non-technical users to create automation. Visualization tools like FigJam and Zeppelin increase shared understanding in organizations.The software industry is shifting towards smaller organizations and general-purpose work.AI cannot eliminate political games in organizations, as they are driven by cultural factors.There is a need for more focus on edge cases and negative use cases in software development.The responsibility of software professionals is to create good software and address the societal impact of bad software.Gojko's booksCheck out our sponsors:www.xebia.comwww.wiserbees.comwww.scrummatch.comwww.masteringagility.orgSound BitesChapters00:00Introduction01:21Visualizing Specifications03:04Early Experiences with Software Quality04:09Solving Communication Problems05:31Validating Real-World Usage of Spec by Example06:29Getting Permission from Companies for Case Studies08:28Persistent Challenges and Positive Patterns09:49Adoption of Given-When-Then and Consolidation of Tools11:42Identifying Bottlenecks and Visualizing Problems13:01Causing Organizational Change14:09The Challenge of Change Resistance16:30The Evolution of Software Development Solutions26:48Goiko's Recent Work and Projects35:26The Power of Expressing Human Knowledge in Software36:03Visualization Tools and Increased Shared Understanding37:27Specialists vs. Generalists in the Software Industry38:49The Shift Towards Smaller Organizations and General Purpose Work41:49The Role of AI in Minimizing Political Games in Organizations42:54The Responsibility of Software Professionals in Creating Good Software51:01The Need for Spending More Time on Edge Cases and Negative Use Cases53:31The Societal Impact of Bad Software and the Role of Governments57:41The Potential for IT to Become a Profession01:01:29The Conservation and Shifting of Complexity in Software Development01:04:43The Impact of Shoddy Software on People's Lives

Poslušajte novu epizodu podkasta Iza vesti sa Gojkom Božovićem

In this episode, Dave Farley chats with Gojko Adzic. Gojko is a prolific author, international speaker on software and expert practitioner in DDD, BDD and an AWS Serverless Hero. Dave and Gojko chat about a wide-ranging series of topics on product development, steering development organisations to success, Palchinsky principles and how agile development failed for the FBI and the BBC. It's a fun episode! ( ➡️ https://gojko.net)xxGojko's new text-to-speech video maker ➡️ https://www.narakeet.com MindMup - MindMapping tools ➡️ https://www.mindmup.com

Podkast "Dobar loš zao" neumorno nastavlja emitovanje i u sred letnje žege! U novoj epizodi Nenad Kulačin i Marko Vidojković upitali su se kako je evolucija skrenula ka Aleksandru Martinoviću, zašto se umesto 61 na glasanju za smenju Gašića našlo svega 37 poslanika opozicije, uputili su podršku policajki Katarini koja je javnosti doturila zapisnik saobraćajne nesreće koju je izazvao kum Nikola, a posebna poslastica bio je razgovor o 14.000 procurelih botovskih naloga. Gošća u ovoj epizodi je uticajna tviterašica, novinarka i aktiviskinja, Biljana Lukić. Gospođa Biljana je, između ostalog, iznela svoje mišljenje o protestima, opoziciji, spremnosti režima na primenu sile i paklu koji nas očekuje sa početkom nove školske godine. U Magarećem kutku, učimo novu reč: izbacati! DLZ, jedini podkast u ovom delu sveta pod zaštitom Međunarodnog PEN centra, na našem portalu, sredom od osam.

Einmal Indianer - immer Indianer! Sagt Gojko Mitić, der seit über 60 Jahren immer wieder Indianer verkörpert hat, im Film und auf der Bühne.

Ko so nekaj kipov iz zbirke s posestva Brdo pri Kranju odpeljali v Park vojaške zgodovine v Pivki, je to sprožilo močan odziv strokovne javnosti, saj je po mnenju številnih premik bil sporen in neutemeljen. Gre za dela uveljavljenih avtorjev iz obdobja po drugi svetovni vojni, zato so na Ministrstvu za kulturo spodbudili razpravo o njihovi prihodnji usodi in organizirali posvet, na katerem je o likovnem vidiku kipov govoril umetnostni zgodovinar mag. Gojko Zupan z direktorata za kulturno dediščino na ministrstvu. V politično razgreti debati se pogosto pozablja prav na likovno vrednost teh del, zato je ta bila med drugim tema pogovora, v katerem razmišlja tudi o našem o odnosu do umetnostne dediščine povojnega obdobja. Foto: BoBo

V epizodi #94 je bil moj gost Goran Hrvaćanin, znan tudi kot Gojko Ajkula. Slovenski igralec, komik, scenarist in producent. V epizodi se dotakneva naslednjih tematik: Podkastanje in Youtube Družba in socialni mediji, cringefluencer Ustvarjanje, trendi in poplava vsebine Prvi skeč, "attention whore" Očetovstvo, alkoholizem in vzorci Odpusti svojim staršem Terapija skozi meditacijo Najbolj gledan slovenski film: Pr' Hostar Odnos do "hate" komentarjev Pr' Hostar 2 Vprašanje prejšnjega gosta ==================================== Prijavi se na newsletter in vsak petek prejmi 5 linkov, ki jih ustvarjalci podkastov Dialog in RE:MOAT izberemo tisti teden (knjige, dokumentarci, članki, podkast epizode …). ============================= Pridruži se kot podpornik kanala AIDEA

Na cilju 26. Ljubljanskega maratona je bil tudi današnji nedeljskji gost, oče največje slovenske športno-rekreativne prireditve, Gojko Zalokar. Je športni zanesenjak, vizionar, človek, ki je s svojo ekipo na ljubljanske ulice zvabil tisoče Slovencev. Z njim je Boštjan Reberšak govoril o tekaških smernicah v svetu in Sloveniji, smernicah tekmovalnega maratona in pripetljajih, ki so spremljali prireditev od začetkov s 673 tekači do rekordne več kot 16-tisoč glave množice.

Komentator analizira poraz nelevice na državnozborskih volitvah in razmišlja, da nam lahko pomagajo nauki iz zgodovine. Anton Mahnič je katoliški strani npr. predložil tri cilje: socialno-gospodarsko reformo, katoliško vzgojo in narodne pravice. O tem, kako doseči volivce pa je pisal tudi škof Jeglič. Stare ugotavlja, da je volilni sistem v Sloveniji prirejen za levico, deluje namreč od zgoraj navzdol in ker nelevica nima medijske podpore bo pač morala zgraditi svoje volilno telo od spodaj navzgor. Stare poziva k povezovanju v nekakšen Demos 2.0; Ernesta Petriča pa vidi kot tistega, ki bi lahko odigral vlogo Ivana Omana.

Our series of interactive events in live streaming with our experts, an informal 30-minute chat on their area of expertise where you'll have a chance to interact with them, ask questions and learn straight from the source.The first Small Talk of the year will see the comeback of Gojko Adzic, book author and one of our trainers. Let's understand a bit more about Specification By Example, a book he published in 2011 (which is also the title of his upcoming workshop).In a nutshell, Specification By Example is a collaborative approach to defining requirements and tests based on capturing realistic examples instead of abstract statements.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how Gojko's Specification By Example workshop was born, why it is useful, if it is still relevant after more than 10 years from its creation, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts during the class.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Specification By Example, Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: https://bit.ly/SpecificationByExample_Podcast#SpecificationByExample #SoftwareTesting #Testing #ProductOwner #SoftwareDevelopment #Communication #Implementation #Team #TeamWork #SoftwareDeveloper #SoftwareTester #Agile #Scrum #Kanban #UserStory #Software #Test #Example #Lean #LeanThinking #ExtremeProgramming #Requirements #ImpactMapping #Requirements

Our series of interactive events in live streaming with our experts, an informal 30-minute chat on their area of expertise where you'll have a chance to interact with them, ask questions and learn straight from the source.The first Small Talk of the year will see the comeback of Gojko Adzic, book author and one of our trainers. Let's understand a bit more about Specification By Example, a book he published in 2011 (which is also the title of his upcoming workshop).In a nutshell, Specification By Example is a collaborative approach to defining requirements and tests based on capturing realistic examples instead of abstract statements.Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how Gojko's Specification By Example workshop was born, why it is useful, if it is still relevant after more than 10 years from its creation, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts during the class.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Specification By Example, Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: https://bit.ly/SpecificationByExample_Podcast#SpecificationByExample #SoftwareTesting #Testing #ProductOwner #SoftwareDevelopment #Communication #Implementation #Team #TeamWork #SoftwareDeveloper #SoftwareTester #Agile #Scrum #Kanban #UserStory #Software #Test #Example #Lean #LeanThinking #ExtremeProgramming #Requirements #ImpactMapping #Requirements

Introducing Small Talk, our new series of interactive events in live streaming. Each episode will feature one of our experts and we'll have an informal chat on their area of expertise.This time we talk with Gojko Adzic, book author and one of our trainers, about Impact Mapping (which is also the title of his upcoming workshop).Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how his Impact Mapping workshop was born, Gojko's writing routine, why Impact Mapping is useful, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts of the workshop.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: http://bit.ly/Gojko_Adzic_PO_Key_Skills_Avanscoperta_Podcast#ImpactMapping #ProductOwner #ProjectManagement #ProjectMgmt #Agile #Scrum #Kanban #GojkoAdzic #SpecificationByExample #SoftwareTesting #Software #SoftwareDevelopment

Introducing Small Talk, our new series of interactive events in live streaming. Each episode will feature one of our experts and we'll have an informal chat on their area of expertise.This time we talk with Gojko Adzic, book author and one of our trainers, about Impact Mapping (which is also the title of his upcoming workshop).Small Talk is a chance to go behind the scenes of our experts' work and get a sneak peek of what their workshop will be about and, as usual, you'll be able to join the conversation by asking questions from home.Always wanted to ask a trainer that burning question about what they do? Now you have a chance!We'll discuss how his Impact Mapping workshop was born, Gojko's writing routine, why Impact Mapping is useful, what type of professionals will benefit from this the most, what type of exercises we'll be doing in the workshop and how these will enable you to learn the key concepts of the workshop.Did we say it already? You're encouraged to be part of the conversation and ask questions during the live streaming through the chat provided by YouTube.Who: Gojko Adzic is a partner at Neuri Consulting LLP. He is the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award.Author of: Impact Mapping, Fifty Quick Ideas To Improve Your User Stories, Humans vs Computers.Workshop link: http://bit.ly/Gojko_Adzic_PO_Key_Skills_Avanscoperta_Podcast#ImpactMapping #ProductOwner #ProjectManagement #ProjectMgmt #Agile #Scrum #Kanban #GojkoAdzic #SpecificationByExample #SoftwareTesting #Software #SoftwareDevelopment

Kakšen človek in kakšne neverjetne zgodbe! V pol stoletja je oblikoval in zgradil rekreativno okolje v Sloveniji, zaradi katerega dandanes v tekaški rekreaciji sodimo v sam svetovni vrh. Gojko Zalokar, legenda, športnik po duši in telesu je dolgoletni in doslej edini direktor Timinga Ljubljana in Ljubljanskega maratona. V kratkem po bogati karieri odhaja v pokoj, a ostaja vitalni del naše največjega tekaškega praznika. Predsednik Združenja za rekreativne teke išče tudi odgovore na izzive postkoronske tekaške realnosti. Če vas vsaj malo zanima, kako se je pred pol stoletja vse začelo in kaj se je dogajalo do danes, poslušanje obvezno!

Episode Summary: In this episode, Raymond and I explore: If it's possible for organisations to be 100% agile, Why a human-centred approach to product design is key How one can get started with their agile journey... and much more.   Guest Bio: Raymond Chike has over 15 years diversified experience in the Financial, Retail, Utilities, Energy, Consulting and Charity sectors. Proven record as a problem solver and aggressive commitment to continuous learning. Bringing together Human, Digital and Physical Interactions while enjoy working with businesses create innovative solutions, products and services. By recognising customer needs, validating new product and service concepts, assisting teams in developing mvp, and assisting organisations in transitioning to adopting new ways of working in a holistic human-centric way.   Raymond's Social Media: LinkedIn: https://www.linkedin.com/in/chykeray/   Design Thinking Squad Meetup https://www.meetup.com/Design-Thinking-Squad-Gloucestershire/   URLs and Resources Mentioned Books/ Articles: User Story Mapping by Jeff Patton The Startup Way by Eric Reis Lean Startup by Eric Reis Lean UX: Designing Great Products with Agile Teams by Jeff Gothelf and Josh Seiden Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden Impact Mapping by Gojko Adzic Raymond's LinkedIn post on relationship between Design Thinking, Lean and Agile: https://www.linkedin.com/feed/update/activity:6505691705440894976/   Interview Transcript  Ula: 00:26 Hey everyone! How are you doing today? Can you believe it? We're nearly at the end of Season 1 of the Agile Innovation Leaders podcast and this is our 9th episode. A massive thank you and shout out to all of you who have taken the time to listen, support, to write, to encourage… I am very, very grateful. It never ceases to amaze me that you guys are listening from all over the world; from places and countries like New Zealand, Australia, Singapore, India, Nigeria, Kenya, Ghana, France, South Africa, Canada, USA, Brazil, Switzerland, Norway… of course United Kingdom where we live and many other places where I've not mentioned. I do appreciate the engagement – thank you so much. Keep it coming and keep getting in touch. Now, in the course of launching the podcast, I've also had a number of you get in touch with me to say, ‘Hey, we really are interested in this ‘Agile' thing. How can we learn more about it? How do we get started?' And for some of you, you've had some sort of Agile initiatives going on in your organization and you don't know how you can make this better, make it work because it's not working as well as it should. Well, if you fall into any of these categories, today's episode is for you. I'm pleased to introduce my guest. He is nobody else other than Raymond Chike. A seasoned Agile Innovation professional with over 15 years of diversified experience in multiple sectors – Financial, Retail, Utilities, Energy, Consulting and Charity. And he is a big proponent of design thinking and basically blending agile, lean start up thinking, UX design and design thinking to provide a rounded and human-centered way of working. You just have to listen to this episode! So without further ado, my conversation with Raymond. Enjoy! Ula: 03:04 Raymond, thanks for making the time for this conversation. It's great to have you on the show. Raymond: 03:09 You're welcome. I'm excited as well Ula: 03:11 Great. Now let's kick off. We want to know who Raymond is as an individual. Can you tell us a bit about yourself, and how your life experience has led you to choosing a career as an agile professional? Raymond: 03:25 My story is one of those I'm passionate about telling people. So, I'm a native of Nigeria, back in Africa. And I think the whole journey started off as me looking at the whole world in perspective. And I thought to myself, I want to see how things get done in the Western world – United Kingdom and America and all that. That led me to journey into the UK. So, on coming here, I found my first contract was more of an IT security administrators service contract or something like that. And along the line, I started noticing that I was good at connecting the business and the technology. Little did I know that that was what business analysis was. Then, business analysis became popular, but already I'd found out I was naturally a Business Analyst. But then I thought, ‘Okay, let's go on that journey.' And while in the journey of a Business Analyst, I started realizing that things took too long to happen. So, people are building (a) project and before the project finishes, in two years, the world has moved on. And I said, what is the best way of doing things quicker. I mean, that was where agile started coming up in my mentality. Then I thought, ‘Alright, I think I've got an agile mindset as well.' So, I think I'll take a perspective from a natural point. So, professionally, that's how I found my way/ journey into the Agile world. I live in the UK, permanently now for 14 years, 15 years or so. I've got (a) family, as well. So, my primary location is around Southwest of Cheltenham, but most of my consultancy has been around London, and I travel around anyway. I think. Yeah, that's me in a nutshell, and that's my passion. And, then yeah. Ula: 05:11 That's quite an interesting story. It's funny, because we all start off one way, but the thing about us as humans is that there are things about yourself, you know, your natural inclinations or giftings, or things you're really good at, you wouldn't know until you actually get started. So, it's interesting you recognised the knack (i.e. abilities) and probably people around you also recognise the knack whilst working as an IT Security Specialist, that you also had the ability to connect business with technology. Just out of curiosity, what was your educational background? Raymond: 05:46 Yeah, I graduated with a first degree in Electrical/ Electronics Engineering. Ula: 05:50 Oh, okay. Raymond: 05:51 And… yeah, that is me really. I haven't furthered anyway in terms of educational academia. I've surrounded myself with lots of training and certifications… I've gone, I mean… I don't know if I have enough time to start to name them. But, that's my educational background anyway. Ula: 06:11 I mean, education is not necessarily having more degrees or as many degrees as a thermometer. I'm also Nigerian and I also got my first degree - funnily also in Electronic Engineering. Raymond: 06: 21 Really? Ula: 06:22 Yeah, yeah. Raymond: 06:23 What a coincidence! Ula: 06:26 From your profile, I can see that you are quite big on marrying agile thinking with lean, UX design and design thinking. I'm a big fan of that, because it's really about focusing on what value you're bringing to the customer, whether it's internal or external, and ruthlessly eliminating anything that the customer does not value and is not willing to pay for. So, what are your thoughts on marrying design thinking with lean methodologies? Raymond: 06:56 My thoughts are certain in the sense that it must be married. Looking at the world we live in now, (we're) in an adaptive world. I think the most important service to me is customer service. At the heart of every product, at the heart of everything we do, if we can't link it to customer service, then we just building what we think we like, yeah? And before you can build something for a customer, I always look at it in this perspective, you have to design that thing, you have to then build it, and you have to engage with the people to use the product. And that's the heart of Human Centered Design, or rather you can call it Customer Centric way of doing something. So, that is me thinking about how you bring together the human perspective, and link it with the digital and the physical interaction. Now, this is where you need to combine a whole lot of techniques and thinking and I always say it this way, ‘Agile is not a way of working, agile is a way of thinking than the way working.' Because your behavior modification cannot change if your mind is not transformed. So, at the center and the heart of agile, is the thinking. The same applies to design; at the center and heart of design is thinking - Design Thinking, Agile Thinking. So, call it this way: Design Thinking, Lean Thinking, and Agile Thinking. And to marry them is - Design Thinking makes you get to the heart of the customer. Like, ‘What is the problem you're about to solve? What is the pain point? Empathy. What is this? Why are we doing this thing? What is the problem? The pain point; you empathise with the customer. Now, at that point of empathy - this is where you begin to think about Lean. Where Lean thinks, ‘All right, I think I've empathised (with) this problem and I understand this thing – I feel I understand it.' Then, what's the barest minimum I can test to see it's working? This is where Lean Thinking comes in, right? So, then when you use the Lean Thinking and it works or you get good feedback (you say), ‘Okay, okay. I think we now see a way this is gonna work.'  ‘Okay, let's produce it in some sort of scale now and still get feedback and learn.' This is where you now bring in the principles on Agile, like the Scrum, and the Kanban, or the Extreme Programming, or SAFe (Scaled Agile Framework). Then you now want to say, ‘Okay, this thing is getting bigger now; we're about to blow up now', so you want to scale. You scale the product, you engage with the people, then you might… So this is the journey of a product from its inception of human-centric pain point up to the development, and this is how I marry Design Thinking, Lean Thinking and Agile Thinking. Ula: 09:41 Wow, (I've) never really heard it put this way. But it does make sense and I do agree. So, would you say that Design Thinking is the same thing as User Experience design? Raymond: 09:51 It's an interesting conversation but it's not the same. But what I usually say - Design Thinking is a big umbrella. Like, you'd say, Agile thinking. So if you… Like, what you've asked me now is like, ‘Is Agile thinking the same as Scrum Master?' It's like, ‘Oh no, Scrum Master sits under Agile.' That's the same question. Design Thinking involves a lot of skills. Ula: 10:16 Yes Raymond: 10:17 Now, it depends on the way you want to go with it. If you want to do a short design… bear in mind it's a (way of) thinking. Ula: 10:23 Yeah Raymond: 10:23 If you now want to bring it to reality, in terms of skill you might want to map it to, say, a researcher can be involved. A researcher... Now does that mean you cannot be a researcher? You can be (one) but in a professional office, maybe there's a (dedicated) researcher. Okay, UX design - alright, what makes you think you're not a UX designer? Okay, I want to develop an app. I can just sketch something on paper with a wireframe and I've got some understanding of UX concepts. Now, that's my minimum viable (product). Maybe I need a professional UX designer to a prototype for me. Okay, then you need a UX (designer) it might be - depends on the product. If my product is around…  (say,) building a bottle, I don't need a UX designer for a bottle. I might just go get a fabricator to make a bottle, you see what I mean? So regardless of the product, the principles stand. But when you talk about the product you want to do maybe a web design, then the skill set comes into play. That is why the UX design now is a skill. Yeah, that's a connection. So, it's like Agile - is Agile the same as… product owner? No, within agile umbrella, we might need a product owner, we will need a scrum master. Okay, maybe we don't need an engineer really. Okay, okay. While you're developing an agile product, what if the product is a pharmaceutical product? Do you need a developer? No, you need the scientist. So, you see the point. So, the takeaway, because when we talk about Lean agile, people just focus straight ‘Oh! (We're building a) website, app?' Ula: 11:49 Software development… Raymond: 11:50 But… it's not about websites. It's not about apps, not about it. What if it is a pharmaceutical company developing a prosthetic leg or pharmaceutical company developing a fake eyeball, what do you say then, you know? So, I try to get people away from products first, think about the human-centric way of connecting digital and physical interaction, then I think everything will fit into place. Ula: 12:15 It's interesting how you've highlighted the fact that there are general principles underpinning Agile thinking or Design thinking and the principles are separate from the products. Now the products could vary, the principles remain pretty much the same. But now depends on the context - which you can now adapt it (the principles) to the context of the product or service probably that you're providing to the end user or the customer. Am I right? Raymond: 12:44 That's right, well-articulated. Ula: 12:47 Okay, well, thanks. That's interesting. You said that there is this misconception that agile is about the things people do. Now, based on what you're saying that agile is first a mindset so and the International Consortium for Agile, or the ICAgile organization, they said on their website, it's about first being agile, before you do agile. Raymond: 13:11 That's right. Ula: 13:12 So, what would you say are the steps then, towards being agile and when would you know that you are truly agile from a ‘being' standpoint? Raymond: 13:24 Okay, I think the best way to say (it is) this way: there is nobody that's 100% agile. Ula: 13:30 Hmm! Interesting. Yeah. Raymond: 15:31 Definitely, nobody, nobody. Because why I say that is, if you are 100% agile, it's like… if you say yes, I am 100% agile, it does not marry up with the name agile itself, because agile itself means changing. So, you say you're 100% changing. So, I am 100% changing, so you're still changing. So, what agile, what I try to say about agile is (it's) about how we're learning that's Agile. So, (it) automatically tells you, you are constantly learning. So, have you learnt? No, you are constantly learning. So, the thing at the core of Agile is a mindset, your mind has to be ready. That's the height of it is your mindset knows that things must change. The principles and the values lie within and the practices follow and the tools and processes that help it. So, but you need to get at the heart of it that it… So basically, the world, is ruled by companies who learn faster. That's it. So, how are you learning faster? That's why agile comes in. So, are you… if Facebook comes tomorrow and said, ‘We are now agile; we are the best agile (practitioners)', that's wrong, because they're still going to have challenges that come up tomorrow that they'd have to think and say, ‘Guys, what's the next solution here?' Ula: 14:46 True Raymond: 14:46 This is where I feel agile is just, agile in itself is even a part of a product. As I've just explained Lean, design thinking, lean and agile… all that stuff. So, it's a complete mindset shift. But we there yet? We're not always going to be there in terms of 100%. But we are on a journey. Ula: 15:06 Yeah Raymond: 15:06 So, we're on a journey… we're not definitely going to be ‘there'. So, to answer your question, I don't think anybody's 100% agile. But I guess the thing is, to what degree of Agile are you? To what degree of learning or what degree of flexibility? What degree do you apply the principles better? I think that's the key message. And I mean, the only way to answer that is more of your outcomes, really? So, when you check into your outcomes, you know if you are really, truly agile and how responsive you are to the market and how adaptive you are. Ula: 15:41 Well put. So you said, yes, no one is 100% agile. You're constantly learning and that's probably why agile and lean - they're complimentary because lean is also about continuous improvements and focusing on improving processes to achieve certain goals. What would you say about the frameworks then? Is it possible to purely apply one framework in an organization's operating context, to the exclusion of others? Raymond: 16:13 Great question. I think you will do yourself a favor to mix them up. I always tell people this … if you study Scrum, the next thing… they (people in organisations) call me and say, ‘I'm doing Scrum', (and the person) goes on saying ‘I'm writing user stories.' And I say, ‘Okay, but I'm sorry, user story is Extreme Programming. So, you're already mixing it up, right? Then you get people who are doing Scrum. Then they go, ‘Oh, our Jira board is a Scrumban board.' So, what's that about? Ula: 16:41 It's a Kanban board… yeah… Raymond: 16:42 So, what I tell people is this: I'm not dogmatic about any (framework). If you bring any framework tomorrow and call it… ‘Jump' … whatever you want to call it. My question to you (would be), ‘Is it solving human problems? Are we inspecting and adapting faster? Is it prioritizing collaboration over ‘blah'…? Is it prioritizing responding to change over following a plan? Is it tied to the principle?' (If the answer is) ‘Yes', that's it! I don't want to know what else you call the name. I mean, I was in a conference the other day and I said to someone, ‘Look, let's be honest.' (If) she goes to Facebook now, (and) I go to Netflix (and) ask them what (agile framework/ methodology) they're following, they probably would not tell you anything. Probably tell you, ‘I don't know what's Scrum - we just inspect and adapt quickly. We just learn fast. We have a system that helps us learn fast.' That's it. No one is gonna tell you, ‘Do three weeks sprint, do four weeks sprint… do one thing or the other…' It depends on the product. Depends on the product. Some people do one-week sprint. Some companies do one-week sprint, two weeks sprint, three weeks sprint. Some pharmaceutical companies do one-week experimentation. I've seen companies do design sprint zero, then go on and do one-week sprint. The thing is, where are you learning fast? How are you learning fast? And agile is just (a means to) the end game; it's the building of the product. Remember, I said design thinking? Where is the place (for empathy in Agile)? …No agile principle talks about empathy. Nothing like that. Ula: 18:05 No Raymond: 18:06 They (some agile frameworks) just tell you, ‘Sprint planning - boom, boom, boom, go!' But, how do I know the product to build? I mean, this was what inspired me to (write) my last post where I said… I did post something on LinkedIn the other day. (That's one of) the key things that I was trying to say to the team. I read that from a book called The Startup Way by Eric Ries. This is the same guy who … Eric Ries is The Lean Startup guy. So, here is Toyota (for example). Toyota known for all the things they do around production and lean and all that stuff. But yet someone in Toyota could say he thinks there's a missing part. And that is because they are good at creating things. But they don't have a system that tells them on (how to) discover what to produce. Scrum does not help you discover what to produce, you know… Kanban does not help you discover what to produce. They just help you produce but they don't help you discover. So, this is why I say, I'm not precious about any framework, as long as that framework can help me easily inspect and adapt. That is my key (requirement)… and it's transparent. That's my own, I don't really cherish… I'm not gonna say I'm a SAFe man (or it) must be SAFe. (Nor would I say) it must be Scrum, or it must be Kanban. But then, does it mean I haven't gone on training for all of them? I have – I'm not hung up on frameworks. (I've gone on training for every one of them) because I want to know what I'm talking about. I want to learn because I'm also an aggressive learner. So, I want to know what you're talking about. But then I always ask myself the question, what is the “why” you're doing this? Why are you doing it? If it connects with (the agile) principles – yes. If it doesn't… hmmm… I'll pick and choose what I want from it and throw the rest away. As simple as that. That's my view on all frameworks, really. Ula: 19:48 Makes perfect sense, actually. Raymond: 19:51 You don't want to be hung up around frameworks really. Going into this conversation the other day, someone talked about (the) product owner (role) and I said, ‘Listen, I've done a Product Owner course for Scrum. And that is not up to 2% of what it takes to be a Product Manager.' It's not! If you think you've done a Scrum course, on product ownership, and you think you are now a product owner? I'm sorry, it's not (the case). Because the Product Management (responsibility) is a big piece - from design, to engagement, to development. So, there you have several of those sideline courses, you have to go to; to understand the market, to understand the proposition, to understand business model presentation, Lean Canvas…, then, you know what I mean? Where goes all the certifications and frameworks again? It's all about just learning. Just see it all as learning; adding that to your toolbox. You know, focus on the human-centric problem you want to solve. Ula: 20:44 I quite resonate with what you said. As in likening these frameworks, the concepts - to look at them as tools in a toolbox. You pick the one that most appropriately suits the work and the organization you are in - in my opinion. I'd like to know what you think about this. But I also think it is possible that a team, an organization you know, or even within a project, it could evolve in such a way that the tools that you're using… or the practices and the tools and processes that you're using to try to accomplish an outcome might need to change midway. So, it doesn't necessarily mean that what you start with is what you end with at the end of the project. What do you think about that? Raymond: 21:30 Yes, I mean, it is. I've worked with several big companies trying to do agile or are doing agile. I've seen it. I've got the scars on my back. I know what I'm am saying. It's very painful when you see people who want to fix it (an ill-fitting framework) into their hole. I say to them, ‘You have to be pragmatic.' Like this consultant… I don't remember his name again. But he said, ‘Agile has a way of making people drop their smart brains at home and come to work.'  If you come to work, (that) you do agile doesn't mean you're not smart - you're smart. Just know that you're smart. Look around the process, see how it's going to work well for you. If it's not working, find another way it's going to work. Remember, the principles still apply. Keep the principles at your forefront. We're talking real stuff here, yeah? So how do we make Kanban work for us? How do we make Scrum work for us? Okay, yes. Okay. How do we draw funds, investment? Because we need seed funding to do this experiment and prove to our manager it works. Okay, you want to start up something now? You're starting small? You're (i.e. Ula is, for example) not going out now opening an office and buying a podcast device of 10 grand or 20 grands? You're being lean here; trying to make sure you're experimenting here, right? Ula: 22:39 Exactly, you have to know if someone wants… Raymond: 22:41 You (Ula) are applying the same principles. You've got the mindset; you've got the mindset. That why you're doing what you're doing right now. And it's the same principle applied at a scale. Ula: 22:49 Thanks! You mentioned something that you've had scars on your back as a contractor working with teams and organizations. Is there any one you wish to share? Raymond: 22:58 I think for me, the behavior is the same. What I can say is, every company wants to be agile; that's the market drive - just get that right. Every company wants to be agile. In fact, you can almost sell anything to any company now in the name of Agile. Ula: 23:12 It's a buzzword, right? Raymond: 23:14 Yes. But then I always say this, ‘If I get in there, how can I add value to you?' So, you get in there, you stumble on arguments. Now one coach prefers SAFe (Scaled Agile Framework), another Coach tell you Scrum, another coach tells you Kanban is the way. Then I always challenge them by saying… When I come in with design thinking mentality, they look at me like, ‘where does this guy come from? Who are you? We are agile.' I say, ‘yes, but how do you draw funds from the manager to tell him you're agile?' They'll say ‘Hmm! That is a Product Manager's responsibility.' I say, ‘Oh really? I thought that's still under Agile, because a  Scrum Product Owner course teaches them (i.e. the Product Managers) how to draw money? Is it a “no”? Okay'. You see, when you find that a… That's what you see in companies. I think what we need to start to understand is…  I tell people, ‘Guide yourself with mentors', experience is key as well, you know. My experience, tells me that many companies are still on the journey, and I said agile is a journey. My gauge tells me every company now knows: there's no argument we have to be agile. So, we've crossed that stage. They know that we have to be adaptive. They know that now. The challenge many companies are facing now is, ‘How?' They now know, but it's the ‘how' now. (My) advice is, based on my experience, there is no pattern. All I can say is, as long as you have these three pillars in the mindset of what you do; the design thinking, lean thinking, agile thinking… I always wrap it up by saying (you must have) almost an entrepreneurial mindset as well. Ula: 24:46 Oh yeah. Raymond: 24:47 That will help. A bit of that will very, very help (i.e. help very much). The reason why I say entrepreneurial mindset is because then you're thinking differently. You are not there sitting down in a company waiting for your salary every month and just go home. You're inspired to say, ‘What problem are we solving? What customer problem are we solving out there? How can we be fruitful?' Now you're thinking entrepreneurial. I think that drive will start to send a different message to company structures; you start inspire people to work, in fact inspire people for new products. And because people love working agile, when you put agile in any office, (for example) Kanban, people love it. Why? Because it is liberating. Ula: 25:27 It is. The transparency... Raymond: 25:28 It has that way of making… The transparency! People love it. That's the key to (the) successful companies we see these days everywhere. We don't know how they succeed. But this is the principle they've been applying years ago when it was not branded anything. Now is becoming branded, whatever we call it now. Ula: 25:44 Yeah, I mean, it's interesting… Yeah… it helps to put a name to something but it's more about not enshrining it and kind of stifling the spirit of what that thing is meant to mean (therefore) losing the value. Raymond: 26:00 Yeah, I agree with you 100%. Ula: 26:02 Now, you mentioned the book, The Startup Way and I assume that you might have read some other books. If you were to gift or recommend, say two or three more books that have greatly shaped your thinking; your agile, lean, design thinking - which ones would you recommend? Raymond: 26:21 Wow, there are key ones, I think, if you want to be different. If you want to be ‘agile- different', like I mean, set yourself apart. You need to have a hold of this set of books, you know. I would say go for The Startup Way (by Eric Ries), Lean Startup (book by Eric Ries), Lean UX, Impact Mapping by Gojko, User Story Mapping by Jeff Patton. These would get you started. Ula: 26:47 Okay Raymond: 26:48 These are books I've seen that stood the test of time when it comes to this whole ‘game' of Agile. You, kind of… They will set you apart in your Agile thinking. Someone is going to be like, ‘You just became holy again in agile.' I'm telling you. With every page you read in this book, you'll probably read them again and again and you'll be wondering, ‘Where have I been in this world?' Ula: 27:11 Kind of reminds me, there are some books that I have read yet across different disciplines - although I tend to read more of business and self-improvement books. And there are some that are out there, which I'dd read quickly and I'll make a mental note to read them again at a slower pace. However, I also have a lot queued up. Raymond: 27:31 I have so many books but I buy physical books. Ula: 27:33 Yeah Raymond: 27:34 The kind of books I buy are around technology, innovation, entrepreneur… Ula: 27:38 So, there might be other professionals out there or people who want to make a headway into the lean, agile world as consultants or contractors. Now you said you came from Nigeria to the UK, so how did you get your first agile related role? Raymond: 28:00 Yeah, I think it's more of the experience first - in the four walls of the company, that's it I mean, there are two levels I call it like I do some private coaching and training for people who want to get into like a fundamental business analyst role. Then maybe progress to an agile role. But I would say, most of these things... As I said, the first thing is the mind. I always say this, it's difficult to teach you agile, (if) you don't understand Agile, it's difficult. So, I think what I tend to do is… there is a level of experience I hope you'd have experienced in the four walls of a company, deep problems. Then you can do some training or in most cases, enlightening yourself with some of these books. Read them, be sure you understand what they're saying. I always say understand why people use Agile. Don't understand Agile. Just understand why and relate it to your real world. Bring it home. Always bring it home because… How we bring it home? I tell people, look at the things you use from day to day. When you started using WhatsApp, it's not what it is now. WhatsApp started with just a message. There was no video, there was no record, there was no that whole thing. So, there were messages then later. This is agile. They were changing things, giving people what they want, changing it again, adding this, moving the colors. Now, connect Agile to your daily world. Then when you get to the company, it just starts to make sense. Because the companies you might get into, they are also as confused as you think you are. So, I guess the most important thing is passion. Get that passion in your mind. If you are agile, it would come out of your mind(set) and the way you talk, people will now know it's agile. But if you don't have it in your mind, as a project you (need to) change your mind(set). I always teach people this. Look at your life as well. You want to look for a house or a project you want to work on or you want to buy a new car. You thought you wanted to buy a Volvo. Suddenly, as you started going (car shopping), you find out that you don't like a Volvo. You decided to change it (the desired car) into Mercedes, why? Your requirements are changing even as a human - you haven't even gone a month and you've changed three decisions already. So, that is the adaptive behavior the world is (aiming) at. The system can manage it. What technique will manage this changing requirement every day, yet give the business (its desired) business outcomes, give customer, customer satisfaction. This is… my coaching to people is always (to) connect it with your day-to-day life first - make sense (of it). Then every other thing people are talking about can be reality now. Then, you can do the training, you can do the coaching, you can do the workshops, and they all begin to join dots together. I do workshops as well but then that's more… my training and workshops are more experiential. I bring case studies into the room and by time you go out, you understand what it means. Yeah, that's the way I look at it, really. Ula: 31:04 So, are these workshops public? Raymond: 31:06 At the moment, the organisations I consult with – I run them with them. But then I do them public, but that is once in a while. My plan this year is to have some public sessions, but I haven't put them in the calendar yet. I'm still trying to work out what customers want. I'm still going through a design thinking phase around it because I feel I don't want to just produce what I like; I want to see what people really want. And see where I can do something barest minimum that can help satisfy the need. So, say I'm at that stage where I'm a bit lean about it as well. But then I'm also willing to do anything on demand. If there's a certain group of people that come together and say, ‘I want to learn this thing. We're 10 of us, we are 20.' I do things like that sometimes. I did one in Cardiff last year (2018). A group of people came together - 12 of them - said they wanted to understand Business Analysis, how it links to agile and all that stuff. So, I did a bespoke material for them and I went and delivered it for a full one day. So, things like that I can do as well. But as I said, there is no one public (course) at the moment . Ula: 32:14 Okay, fantastic. Once you have finalized your calendar for some public training or workshop events, where would be the best place for (finding) this info? Raymond: 32:25 I think professionally, the best way to get me is LinkedIn. Ula: 32:27 Okay Raymond: 32:29 So, Raymond Chike, LinkedIn, that's the best way to get me professionally. Ula: 32:34 I'll put your LinkedIn profile URL in the shownotes. Raymond: 32:38 Yes. I have a meetup group in Gloucestershire called the Design Thinking Squad.   Ula: 32:43 Okay. Do you have a URL for that? Is it on Meetup? Raymond: 32:47 It's on meetup as well as, a group called Design Thinking Squad Gloucestershire. We did a Design Thinking Crash Course which is only about  2-3 hours. If I get a demand for it, I will arrange something. Ula: 32:59 So, anyone who's interested who probably is listening to this episode that wants to get in touch with you, the best would be your LinkedIn (profile). Okay. Wow, the time does fly when you're having fun. I've enjoyed the conversation. Raymond. Thank you so, so much for making the time. Raymond: 33:17 You are welcome. Ula: 33:18 Do you have any last word for the audience, before we wrap up? Raymond: 44:45 Yeah, I've enjoyed this conversation. Thank you as well for making this happen. I know it's been busy for me to really get the time around it but finally we made it work. We have been very adaptive and true to the nature of agile. I'd say to the listeners out there, keep your dreams alive. And… there's always a way around everything. Keep in touch. And, as I always say, the future belongs to those who learn faster. Ula: 33:54 Thanks a lot Raymond. Raymond: 33:56 Thank you so much.

About Gojko AdzicGojko Adzic is a partner at Neuri Consulting LLP. He one of the 2019 AWS Serverless Heroes, the winner of the 2016 European Software Testing Outstanding Achievement Award, and the 2011 Most Influential Agile Testing Professional Award. Gojko’s book Specification by Example won the Jolt Award for the best book of 2012, and his blog won the UK Agile Award for the best online publication in 2010.Gojko is a frequent speaker at software development conferences and one of the authors of MindMup and Narakeet.As a consultant, Gojko has helped companies around the world improve their software delivery, from some of the largest financial institutions to small innovative startups. Gojko specializes in agile and lean quality improvement, in particular impact mapping, agile testing, specification by example, and behavior driven development.Twitter: @gojkoadzicNarakeet: https://www.narakeet.comPersonal website: https://gojko.netWatch this video on YouTube: https://youtu.be/kCDDli7uzn8This episode is sponsored by CBT Nuggets: https://www.cbtnuggets.com/TranscriptJeremy: Hi everyone, I'm Jeremy Daly and this is Serverless Chats. Today my guest is Gojko Adzic. Hey Gojko, thanks for joining me.Gojko: Hey, thanks for inviting me.Jeremy: You are a partner at Neuri Consulting, you're an AWS Serverless Hero, you've written I think, what? I think 6,842 books or something like that about technology and serverless and all that kind of stuff. I'd love it if you could tell listeners a little bit about your background and what you've been working on lately.Gojko: I'm a developer. I started developing software when I was six and a half. My dad bought a Commodore 64 and I think my mom would have kicked him out of the house if he told her that he bought it for himself, so it was officially for me.Jeremy: Nice.Gojko: And I was the only kid in the neighborhood that had a computer, but didn't have any ways of loading games on it because he didn't buy it for games. I stayed up and copied and pasted PEEKs and POKEs in a book I couldn't even understand until I made the computer make weird sounds and print rubbish on the screen. And that's my background. Basically, ever since, I only wanted to build software really. I didn't have any other hobbies or anything like that. Currently, I'm building a product for helping tech people who are not video editing professionals create videos very easily. Previously, I've done a lot of work around consulting. I've built a lot of product that is used by millions of school children worldwide collaborate and brainstorm through mind-mapping. And since 2016, most of my development work has been on Lambda and on team stuff.Jeremy: That's awesome. I joke a little bit about the number of books that you wrote, but the ones that you have, one of them's called Running Serverless. I think that was maybe two years ago. That is an excellent book for people getting started with serverless. And then, one of my probably favorite books is Humans Vs Computers. I just love that collection of tales of all these things where humans just build really bad interfaces into software and just things go terribly.Gojko: Thank you very much. I enjoyed writing that book a lot. One of my passions is finding edge cases. I think people with a slight OCD like to find edge cases and in order to be a good developer, I think somebody really needs to have that kind of intent, and really look for edge cases everywhere. And I think collecting these things was my idea to help people first of all think about building better software, and to realize that stuff we might glance over like, nobody's ever going to do this, actually might cause hundreds of millions of dollars of damage ten years later. And thanks very much for liking the book.Jeremy: If people haven't read that book, I don't know, when did that come out? Maybe 2016? 2015?Gojko: Yeah, five or six years ago, I think.Jeremy: Yeah. It's still completely relevant now though and there's just so many great examples in there, and I don't want to spent the whole time talking about that book, but if you haven't read it, go check it out because it's these crazy things like police officers entering in no plates whenever they're giving parking tickets. And then, when somebody actually gets that, ends up with thousands of parking tickets, and it's just crazy stuff like that. Or, not using the middle initial or something like that for the name, or the birthdate or whatever it was, and people constantly getting just ... It's a fascinating book. Definitely check that out.But speaking of edge cases and just all this experience that you have just dealing with this idea of, I guess finding the problems with software. Or maybe even better, I guess a good way to put it is finding the limitations that we build into software mostly unknowingly. We do this unknowingly. And you and I were having a conversation the other day and we were talking about way, way back in the 1970s. I was born in the late '70s. I'm old but hopefully not that old. But way back then, time-sharing was a thing where we would basically have just a few large computers and we would have to borrow time against them. And there's a parallel there to what we were doing back then and I think what we're doing now with cloud computing. What are your thoughts on that?Gojko: Yeah, I think absolutely. We are I think going in a slightly cyclic way here. Maybe not cyclic, maybe spirals. We came to the same horizontal position but vertically, we're slightly better than we were. Again, I didn't start working then. I'm like you, I was born in late '70s. I wasn't there when people were doing punch cards and massive mainframes and time-sharing. My first experience came from home PC computers and later PCs. The whole serverless thing, people were disparaging about that when the marketing buzzword came around. I don't remember exactly when serverless became serverless because we were talking about microservices and Lambda was a way to run microservices and execute code on demand. And all of a sudden, I think the JAWS people realized that JAWS is a horrible marketing name, and decided to rename it to serverless. I think it most important, and it was probably 2017 or something like that. 2000 ...Jeremy: Something like that, yeah.Gojko: Something like that. And then, because it is a horrible marketing name, but it's catchy, it caught on and then people were complaining how it's not serverless, it's just somebody else's servers. And I think there's some truth to that, but actually, it's not even somebody else's servers. It really is somebody else's mainframe in a sense. You know in the '70s and early '80s, before the PC revolution, if you wanted to be a small software house or a small product operator, you probably were not running your own data center. What you would do is you would rent it based on paying for time to one of these massive, massive, massive operators. And in fact, we ended up with AWS being a massive data center. As far as you and I are concerned, it's just a blob. It's not a collection of computers, it's a data center we learn something from and Google is another one and then Microsoft is another one.And I remember reading a book about Andy Grove who was the CEO of Intel where they were thinking about the market for PC computers in the late '70s when somebody came to them with the idea that they could repurpose what became a 8080 processor. They were doing this I think for some Japanese calculator and then somebody said, "We can attach a screen to this and make this a universal computer and sell it." And they realized maybe there's a market for four or five computers in the world like that. And I think that that's ... You know, we ended up with four or five computers, it's just the definition of a computer changed.Jeremy: Right. I think that's a good point because you think about after the PC revolution, once the web started becoming really big, people started building data centers and collocation facilities like crazy. This is way before the cloud, and everybody was buying racks and Dell was getting really popular because people buying servers from Dell, and installing these in their data centers and doing this. And it just became this massive, whole industry built around doing that. And then you have these few companies that say, "Well, what if we just handled all that stuff for you? Rather than just racking stuff for you," but started just managing the software, and started managing the networking, and the backups, and all this stuff for you? And that's where the cloud was born.But I think you make a really good point where the cloud, whatever it is, Amazon or Google or whatever, you might as well just assume that that's just one big piece of processing that you're renting and you're renting some piece of that. And maybe we have. Maybe we've moved back to this idea where ... Even though everybody's got a massive computer in their pocket now, tons of compute power, in terms of the real business work that's being done, and the real global value, and the things that are powering global commerce and everything else like that, those are starting to move back to run in four, five, massive computers.Gojko: Again, there's a cyclic nature to all of this. I remember reading about the advent of power networks. Because before people had electric power, there were physical machines and movement through physical power, and there were water-powered plants and things like that. And these whole systems of shafts and belts and things like that powering factories. And you had this one kind of power load in a factory that was somewhere in the middle, and then from there, you actually have physical belts, rotating cogs in other buildings, and that was rotating some shafts that were rotating other cogs, and things like that.First of all, when people were able to package up electricity into something that's distributable, and they were running their own small electricity generators next to these big massive machines that were affecting early factories. And one of the first effects of that was they could reuse 30% of their factories better because it was up to 30% of the workspace in the factory that was taken up by all the belts and shafts. And all that movement was producing a lot of air movement and a lot of dust and people were getting sick. But now, you just plug a cable and you no longer have all this bad air and you don't have employees going sick and things like that. Things started changing quite a lot and then all of a sudden, you had this completely new revolution where you no longer had to operate your own electric generator. You could just plug in and get power from the network.And I think part of that is again, cyclic, what's happening in our industry now, where, as you said, we were getting machines. I used to make money as a Linux admin a long time ago and I could set up my own servers and things like that. I had a company in 2007 where we were operating our own gaming system, and we actually had physical servers in a physical server room with all the LEDs and lights, and bleeps, and things like that. Around that time, AWS really made it easy to get virtual machines on EC2 and I realized how stupid the whole, let's manage everything ourself is. But, we are getting to the point where people had to run their own generators, and now you can actually just plug into the electricity network. And of course, there is some standardization. Maybe U.S. still has 110 volts and Europe has 220, and we never really get global standardization there.But I assume before that, every factory could run their own voltage they wanted. It was difficult to manufacture for these things but now you have standardization, it's easier for everybody to plug into the ecosystem and then the whole ecosystem emerged. And I think that's partially what's happening now where things like S3 is an API or Lambda is an API. It's basically the electric socket in your wall.Jeremy: Right, and that's that whole Wardley maps idea, they become utilities. And that's the thing where if you look at that from an enterprise standpoint or from a small business standpoint if you're a startup right now and you are ordering servers to put into a data center somewhere unless you're doing something that's specifically for servers, that's just crazy. Use the cloud.Gojko: This product I mentioned that we built for mind mapping, there's only two of us in the whole company. We do everything from presales, to development testing supports, to everything. And we're competing with companies that have several orders of magnitude more employees, and we can actually compete and win because we can benefit from this ecosystem. And I think this is totally wonderful and amazing and for anybody thinking about starting a product, it's easier to start a product now than ever. And, another thing that's totally I think crazy about this whole serverless thing is how in effect we got a bookstore to offer that first.You mentioned the world utility. I remember I was the editor of a magazine in 2001 in Serbia, and we had licensing with IDG to translate some of their content. And I remember working on this kind of piece from I think PC World in the U.S. where they were interviewing Hewlett Packard people about utility computing. And people from Hewlett Packard back then were predicting that in a few years' time, companies would not operate their own stuff, they would use utility and things like that. And it's totally amazing that in order to reach us over there, that had to be something that was already evaluated and tested, and there was probably a prototype and things like that. And you had all these giants. Hewlett Packard in 2001 was an IT giant. Amazon was just up-and-coming then and they were a bookstore then. They were not even anything more than a bookstore. And you had, what? A decade later, the tables completely turned where HP's ... I don't know ...Jeremy: I think they bought Compaq at some point too.Gojko: You had all these giants, IBM completely missed it. IBM totally missed ...Jeremy: It really did.Gojko: ... the whole mobile and web and everything revolution. Oracle completely missed it. They're trying to catch up now but fat chance. Really, we are down to just a couple of massive clouds, or whatever that means, that we interact with as we're interacting with electricity sockets now.Jeremy: And going back to that utility comparison, or, not really a comparison. It is a utility now. Compute is offered as a utility. Yes, you can buy and generate compute yourself and you can still do that. And I know a lot of enterprises still will. I think cloud is like 4% of the total IT market or something. It's a fraction of it right now. But just from that utility aspect of it, from your experience, you mentioned you had two people and you built, is it MindMup.com?Gojko: MindMup, yeah.Jeremy: You built that with just two people and you've got tons of people using it. But just from your experience, especially coming from the world of being a Linux administrator, which again, I didn't administer ... Well, I guess I was. I did a lot of work in data centers in my younger days. But, coming from that idea and seeing how companies were building in the past and how companies are still building now, because not every company is still using the cloud, far from it. But not taking advantage of that utility, what are those major disadvantages? How badly do you think that's going to slow companies down that are trying to innovate?Gojko: I can give you a story about MindMup. You mentioned MindMup. When was it? 2018, there was the Intel processor vulnerabilities that were discovered.Jeremy: Right, yes.Gojko: I'm not entirely sure what the year was. A few years ago anyway. We got a email from a concerned university admin when the second one was discovered. The first one made all the news and a month later a second one was discovered. Now everybody knew that, they were in panic and things like that. After the second one was discovered, we got a email from a university admin. And universities are big users, they need to protect the data and things like that. And he was insisting that we tell him what our plan was for mitigating this thing because he knows we're on the cloud.I'm working on European time. The customer was in the U.S., probably somewhere U.S. Pacific because it arrived in the middle of the night. I woke up, I'm still trying to get my head around and drinking coffee and there's this whole sausage CV number that he sent me. I have no idea what it's about. I took that, pasted it into Google to figure out what's going on. The first result I got from Google was that AWS Lambda was already patched. Copy, paste, my day's done. And I assume lots and lots of other people were having a totally different conversation with their IT department that day. And that's why I said I think for products like the one I'm building with video and for the MindMup, being able to rent operations as a utility, but really totally rent ops as a utility, not have to worry about anything below my unique business level is really, really important.And yes, we can hire people to work on that it could even end up being slightly cheaper technically but in terms of my time and where my focus goes and my interruptions, I think deploying on a utility platform, whatever that utility platform is, as long as it's reliable, lets me focus on adding value where I can actually add value. That makes my product unique rather than the generic stuff.Jeremy: You mentioned the video product that you're working on too, and something that is really interesting I think too about taking advantage of the cloud is the scalability aspect of it. I remember, it was maybe 2002, maybe 2003, I was running my own little consulting company at the time, and my local high school always has a rivalry football game every Thanksgiving. And I thought it'd be really interesting if I was to stream the audio from the local AM radio station. I set up a server in my office with ReelCast Streaming or something running or whatever it was. And I remember thinking as long as we don't go over 140 subscribers, we'll be okay. Anything over that, it'll probably crash or the bandwidth won't be enough or whatever.Gojko: And that's just one of those things now, if you're doing any type of massive processing or you need bandwidth, bandwidth alone ... I remember T1 lines being great and then all of a sudden it was like, well, now you need a T3 line or something crazy in order to get the bandwidth that you need. Just from that aspect of it, the ability to scale quickly, that just seems like such a huge blocker for companies that need to order provision servers, maybe get a utility company to come in and install more bandwidth for them, and things like that. That's just stuff that's so far out of scope for building a business to me. At least building a software business or building any business. It's crazy.When I was doing consulting, I did a bit of work for what used to be one of the largest telecom companies in the world.Jeremy: Used to be.Gojko: I don't want to name names on a public chat. Somewhere around 2006, '07 let's say, we did a software project where they just needed to deploy it internally. And it took them seven months to provision a bunch of virtual machines to deploy it internally. Seven months.Jeremy: Wow.Gojko: Because of all the red tape and all the bureaucracy and all the wait for capacity and things like that. That's around the time where Amazon when EC2 became commercially available. I remember working with another client and they were waiting for some servers to arrive so they can install more capacity. And I remember just turning on the Amazon console. I didn't have anything useful to running it then but just being able to start up a virtual machine in about, I think it was less than half an hour, but that was totally fascinating back then. Here's a new Linux machine and in less than half an hour, you can use it. And it was totally crazy. Now we're getting to the point where Lambda will start up in less than 10 milliseconds or something like that. Waiting for that kind of capacity is just insane.With the video thing I'm building, because of Corona and all of this remote teaching stuff, for some reason, we ended up getting lots of teachers using the product. It was one of these half-baked experiments because I didn't have time to build the full user interface for everything, and I realized that lots of people are using PowerPoint to prepare that kind of video. I thought well, how about if I shorten that loop, so just take your PowerPoint and convert it into video. Just type up what you want in the speaker notes, and we'll use these neurometrics to generate audio and things like that. Teachers like it for one reason or the other.We had this influential blogger from Russia explain it on his video blog and then it got picked up, my best guess from what I could see from Google Translate, some virtual meeting of teachers of Russia where they recommended people to try it out. I woke up the next day, the metrics went totally crazy because a significant portion of teachers in Russia tried my tool overnight in a short space of time. Something like that, I couldn't predict it. It's lovely but as you said, as long as we don't go over a hundred subscribers, we're fine. If I was in a situation like that, the thing would completely crash because it's unexpected. We'd have a thing that's amazingly good for marketing that would be amazingly bad for business because it would crash all our capacity we had. Or we had to prepare for a lot more capacity than we needed, but because this is all running on Lambda, Fargate, and other auto-scaling things, it's just fine. No sweat at all. It was a lovely thing to see actually.Jeremy: You actually have two problems there. If you're not running in the cloud or not running on-demand compute, is the fact that one, you would've potentially failed, things would've fallen over and you would've lost all those potential customers, and you wouldn't have been able to grow.Gojko: Plus you've lost paying customers who are using your systems, who've paid you.Jeremy: Right, that's the other thing too. But, on the other side of that problem would be you can't necessarily anticipate some of those things. What do you do? Over-provision and just hope that maybe someday you'll get whatever? That's the crazy thing where the elasticity piece of the cloud to me, is such a no-brainer. Because I know people always talk about, well, if you have predictable workloads. Well yeah, I know we have predictable workloads for some things, but if you're a startup or you're a business that has like ... Maybe you'd pick up some press. I worked for a company that we picked up some press. We had 10,000 signups in a matter of like 30 seconds and it completely killed our backend, my SQL database. Those are hard to prepare for if you're hosting your own equipment.Gojko: Absolutely, not even if you're hosting your own.Jeremy: Also true, right.Gojko: Before moving to Lambda, the app was deployed to Heroku. That was basically, you need to predict how many virtual machines you need. Yes, it's in the cloud, but if you're running on EC2 and you have your 10, 50, 100 virtual machines, whatever running there, and all of a sudden you get a lot more traffic, will it scale or will it not scale? Have you designed it to scale like that? And one of the best things that I think Lambda brought as a constraint was forcing people to design this stuff in a way that scales.Jeremy: Yes.Gojko: I can deploy stuff in the cloud and make it all distributed monolith, so it doesn't really scale well, but with Lambda because it was so constrained when it launched, and this is one thing you mentioned, partially we're losing those constraints now, but it was so constrained when it launched, it was really forcing people to design things that were easy to scale. We had total isolation, there was no way of sharing things, there was no session stickiness and things like that. And then you have to come up with actually good ways of resolving that.I think one of the most challenging things about serverless is that even a Hello World is a distributed transaction processing system, and people don't get that. They think about, well, I had this DigitalOcean five-dollar-a-month server and it was running my, you know, Rails up correctly. I'm just going to use the same ideas to redesign it in Lambda. Yes, you can, but then you're not going to really get the benefits of all of this other stuff. And if you design it as a massively distributed transaction processing system from the start, then yes, it scales like crazy. And it scales up and down and it's lovely, but as Lambda's maturing, I have this slide deck that I've been using since 2016 to talk about Lambda at conferences. And every time I need to do another talk, I pull it out and adjust it a bit. And I have this whole Git history of it because I do markdown to slides and I keep the markdown in Git so I can go back. There's this slide about limitations where originally it's only ... I don't remember what was the time limitation, but something very short.Jeremy: Five minutes originally.Gojko: Yeah, something like that and then it was no PCI compliance and the retries are difficult, and all of this stuff basically became sold. And one of the last things that was there, there was don't even try to put it in a VPC, definitely, you can but it's going to take 10 minutes to start. Now that's reasonably okay as well. One thing that I remember as a really important design constraint was effectively it was a share nothing platform because you could not share data between two Lambdas running at the same time very easily in the same VM. Now that we can connect Lambdas to EFS, you effectively can do that as well. You can have two Lambdas, one writing into an EFS, the other reading the same EFS at the same time. No problem at all. You can pump it into a file and the other thing can just stay in a file and get the data out.As the platform is maturing, I think we're losing some of these design constraints, and sometimes constraints breed creativity. And yes, you still of course can design the system to be good, but it's going to be interesting to see. And this 15-minute limit that we have in Lamdba now is just an artificial number that somebody thought.Jeremy: Yeah, it's arbitrary.Gojko: And at some point when somebody who is important enough asks AWS to give them half-hour Lamdbas, they will get that. Or 24-hour Lambdas. It's going to be interesting to see if Lambda ends up as just another way of running EC2 and starting EC2 that's simpler because you don't have to manage the operating system. And I think the big difference we'll get between EC2 and Lambda is what percentage of ops your developers are responsible for, and what percentage of ops Amazon's developers are responsible for.Because if you look at all these different offerings that Amazon has like Lightsail and EC2 and Fargate and AWS Batch and CodeDeploy, and I don't know how many other things you can run code on in Lambda. The big difference with Lambda is really, at least until very recently was that apart from your application, Amazon is responsible for everything. But now, we're losing design constraints, you can put a Docker container in, you can be responsible for the OS image as well, which is a bit again, interesting to look at.Jeremy: Well, I also wonder too, if you took all those event sources that you can point at Lambda and you add those to Fargate, what's the difference? It seems like they're just merging into two very similar products.Gojko: For the video build platform, the last step runs in Fargate because people are uploading things that are massive, massive, massive for video processing, and just they don't finish in 15 minutes. I have to run to Fargate, and the big difference is the container I packaged up for Fargate takes about 40 seconds to actually deploy. A new event at the moment with the stuff I've packaged in Fargate takes about 40 seconds to deploy. I can optimize that, but I can't optimize it too much. Fargate is still order of magnitude of tens of seconds to process an event. I think as Fargate gets faster and as Lambda gets more of these capabilities, it's going to be very difficult to tell them apart I think.With Fargate, you're intended to manage the container image yourself. You're responsible for patching software, you're responsible for patching OS vulnerabilities and things like that. With Lambda, Amazon, unless you use a container image, Amazon is responsible for that. They come close. When looking at this video building for the first time, I was actually comparing code. I was considering using CodeBuild for that because CodeBuild is also a way to run things on demand and containers, and you actually can get quite decent machines with CodeBuild. And it's also event-driven, and Fargate is event-driven, AWS Batch is event-driven, and all of these things are converging to each other. And really, AWS is famous for having 10 products that do the same thing effectively and you can't tell them apart, and maybe that's where we'll end.Jeremy: And I'm wondering too, the thing that was great about Lambda, at least for me like you said, the shared nothing architecture where it was like, you almost didn't have to rely on anything other than the event that came in, and the processing of that Lambda function. And if you designed your systems well, you may have some bottleneck up front, but especially if you used distributed transactions and you used async invocations of downstream functions, where you could basically take some data that you needed to pass into it, and then you wouldn't necessarily need that to communicate with anything other than itself to process that data. The scale there was massive. You could just keep scaling and scaling and scaling. As you add things like EFS and that adds constraints in terms of the number of transactions and connections that, that can make and all those sort of things. Do these things, do they become less reliable? By allowing it to do more, are we building systems that are less reliable because we're not using some of those tried-and-true constraints that were there?Gojko: Possibly, but every time you add a new moving part, you create one more potential point of failure there. And I think for me, one of the big lessons when I was working on ... I spent a few years working on very high throughput transaction processing systems. That's why this whole thing rings a bell a lot. A lot of it really was how do you figure out what type of messages you send and where you send them. The craze of these messages and distributed transaction processing systems in early 2000s, created this whole craze of enterprise service buses later that came. We now have this... What is it called? It's not called enterprise service bus, it's called EventBridge, or something like that.Jeremy: EventBridge, yes.Gojko: That's effectively an enterprise service bus, it's just the enterprise is the Amazon cloud. The big challenge in designing things like that is decoupling. And it's realizing that when you have a complicated system like that, stuff is going to fail. And especially when we were operating around hardware, stuff is going to fail badly or occasionally, and you need to not bring the whole house down where some storage starts working a bit slower. You create circuit breakers, you create layers and layers of stuff that disconnect things. I remember when we were looking originally at Lambdas and trying to get the head around that and experimenting, should one Lambda call another? Or should one Lambda not call another? And things like that.I realized, let's say for now, until we realize we want to do something else, a Lambda should only ever talk to SNS and nothing else. Or SQS or something like that. When one Lambda completes, it's going to track a message somewhere and we need to design these messages to be good so that we can decouple different parts of the process. And so far, that helps too as a constraint. I think very, very few times we have one Lambda calling another. Mostly when we actually need a synchronized response back, and for security reasons, we wanted to isolate something to a single Lambda, but that's effectively just a black box security isolation. Since creating these isolation layers through messages, through queues, through topics, becomes a fundamental part of designing these systems.I remember speaking at the conference to somebody. I forgot the name of the person who was talking about airline. And he was presenting after me and he said, "Look, I can relate to a lot of what you said." And in the airline community basically they often talk about, apparently, I'm not an airline programmer, he told me that in the airline community, talk about designing the protocol being the biggest challenge. Once you design the protocol between your components, the message is who sends what where, you can recover from almost any other design flaw because it's decoupled so if you've made a mess in one Lambda, you can redesign that Lambda, throw it away, rewrite it, decouple things a different way. If the global protocol is good, you get all the flexibility. If you mess up the protocol for communication, then nothing's going to save you at the end.Now we have EFS and Lambda can talk to an EFS. Should this Lambda talk directly to an EFS or should this Lambda just send some messages to a topic, and then some other Lambdas that are maybe reserved, maybe more constrained talk to EFS? And again, the platform's evolved quite a lot over the last few years. One thing that is particularly useful in that regard is the SQS FIFO queues that came out last year I think. With Corona ...Jeremy: Yeah, whenever it was.Gojko: Yeah, I don't remember if it was last year or two years ago. But one of the things it allows us to do is really run lots and lots of Lambdas in parallel where you can guarantee that no two Lambdas access the same kind of business entity that you have in the same type. For example, for this mind mapping thing, we have lots and lots of people modifying lots and lots of files in parallel, but we need to aggregate a single map. If we have 50 people over here working with a single map and 60 people on a map working a different map, aggregation can run in parallel but I never ever, ever want two people modifying the same map their aggregation to run in parallel.And for Lambda, that was a massive challenge. You had to put Kinesis between Lambda and other Lambdas and things like that. Kinesis' provision capacity, it costs a lot, it doesn't auto-scale. But now with SQS FIFO queues, you can just send a message and you can say the kind of FIFO ID is this map ID that we have. Which means that SQS can run thousands of Lambdas in parallel but they'll never run more than one Lambda for the same map idea at the same time. Designing your protocols like that becomes how you decouple one end of your app that's massively scalable and massively parallel, and another end of your app that we have some reserved capacity or limits.Like for this kind of video thing, the original idea of that was letting me build marketing videos easier and I can't get rid of this accent. Unfortunately, everything I do sounds like I'm threatening someone to blackmail them. I'm like a cheap Bond villain, and that's not good, but I can't do anything else. I can pay other people to do it for me and we used to do that, but then that becomes a big problem when you want to modify tiny things. We paid this lady to professionally record audio for a marketing video that we needed and then six months later, we wanted to change one screen and now the narration is incorrect. And we paid the same woman again. Same equipment, same person, but the sound is totally different because two different equipment.Jeremy: Totally different, right.Gojko: You can't just stitch it up. Then you end up like, okay, do we go and pay for the whole thing again? And I realized the neurometric text-to-speech has learned so much that it can do English better than I can. You're a native English speaker so you can probably defeat those machines, but I can't.Jeremy: I don't know if I could. They're pretty good now. It's kind of scary.Gojko: I started looking at one like why don't they just put stuff in a Markdown and use Markdown to generate videos and things like that? All of these things, you get quota limits still. I thought we were limited on Google. Google gave us something like five requests per second in parallel, and it took me a really long time to even raise these quotas and things like that. I don't want to have lots of people requesting stuff and then in parallel trashing this other thing over there. We need to create these layers of running things in a decent limit, and I think that's where I think designing the protocol for this distributed system becomes an importance.Jeremy: I want to go back because I think you bring up a really good point just about a different type of architecture, or the architectural design of decoupling systems and these event-driven things. You mentioned a Lambda function processes something and sends it to SQS or sends it to SNS to it can do a fan-out pattern or in the case of the FIFO queue, doing an ordered pattern for sequential processing, which those were all great patterns. And even things that AWS has done, such as add things like Lambda destination. Now if you run an asynchronous Lambda function, you still have to write some code or you used to have to write some code that said, "When this is finished processing, now call some other component." And there's just another opportunity for failure there. They basically said, "Well, if it succeeds, then you can actually just forward it off to one of these other services automatically and we'll handle all of the retries and all the failures and that kind of stuff."And those things have been added in to basically give you that warm and fuzzy feeling that if an event doesn't reach where it's supposed to go, that some sort of cloud trickery will kick in and make sure that gets processed. But what that is introduced I think is a cognitive overload for a lot of developers that are designing these systems because you're no longer just writing a script that does X, Y, and Z and makes a few database calls. Now you're saying, okay, I've got to write a script that can massively scale and take the transactions that I need to maybe parallelize or that I maybe need to queue or delay or throttle or whatever, and pass those down to another subsystem. And then that subsystem has to pick those up and maybe that has to parallelize those or maybe there are failure modes in there and I've got all these other things that I have to think about.Just that effect on your average developer, I think you and I think about these things. I would consider myself to be a cloud architect, if that's a thing. But essentially, do you see this being I guess a wall for a lot of developers and something that really requires quite a bit of education to ramp them up to be able to start designing these systems?Gojko: One of the topics we touched upon is the cyclic nature of things, and I think we're going back to where moving from apps working on a single machine to client server architectures was a massive brain melt for a lot of people, and three-tier architectures, which is later, we're not just client server, but three-tier architectures ended up with their own host of problems and then design problems and things like that. That's where a lot of these architectural patterns and design patterns emerged like circuit breakers and things like that. I think there's a whole body of knowledge there for people to research. It's not something that's entirely new and I think you can get started with Lambda quite easily and not necessarily make a mess, but make something that won't necessarily scale well and then start improving it later.That's why I was mentioning that earlier in the discussion where, as long as the protocol makes sense, you can salvage almost anything late. Designing that protocol is important, but then we're going to good software design. I think teaching people how to do that is something that every 10 years, we have to recycle and reinvent and figure it out because people don't like to read books from more than 10 years ago. All of this stuff like designing fault tolerance systems and fail-safe systems, and things like that. There's a ton of books about that from 20 years ago, from 10 years ago. Amazon, for people listening to you and me, they probably use Amazon more for compute than they use for getting books. But Amazon has all these books. Use it for what Amazon was originally intended for and then get some books there and read through this stuff. And I think looking at design of distributed systems and stuff like that becomes really, really critical for Lambdas.Jeremy: Yeah, definitely. All right, we've got a few minutes left and I'd love to go back to something we were talking about a little bit earlier and that was everything moving onto a few of these major cloud providers. And one of the things, you've got scale. Scale is a problem when we talked about oh, we can spin up as many VMs as we want to, and now with serverless, we have unlimited capacity really. I know we didn't say that, but I think that's the general idea. The cloud just provides this unlimited capacity.Gojko: Until something else decides it's not unlimited.Jeremy: And that's my point here where every major cloud provider that I've been involved with and I've heard the stories of, where you start to move the needle at all, there's always an SA that reaches out to you and really wants to understand what your usage is going to be, and what your patterns were going to be. And that's because they need to make sure that where you're running your applications, that they provision enough capacity because there is not enough capacity, or there's not unlimited capacity in the cloud.Gojko: It's physically limited. There's only so much buildings where you can have data centers on the surface of Earth.Jeremy: And I guess that's where my question comes in because you always hear these things about lock-in. Like, well serverless, if you use Lambda, you're going to be locked in. And again, if you're using Oracle, you're locked in. Or, you're using MySQL you're locked in. Or, you're using any of the other things, you're locked in.Gojko: You're actually not locked in physically. There's a key and a lock.Jeremy: Right, but this idea of being locked in not to a specific cloud provider, but just locked into a cloud in general and relying on the cloud to do that scaling for you, where do you think the limitations there are?Gojko: I think again, going back to cyclic, cyclic, cyclic. The PC revolution started when a lot more edge compute was needed on mainframes, and people wanted to get stuff done on their own devices. And I think probably, if we do ever see the limitations of this and it goes into a next cycle, my best guess it's going to be driven by lots of tiny devices connected to a cloud. Not necessarily computers as we know computers today. I pulled out some research preparing for this from IDC. They are predicting basically from 18.3 zettabytes of data needed for IOT in 2019, to be 73.1 zettabytes by 2025. That's like times three in a space of six years. If you went to Amazon now and told them, "You need to have three times more data space in three years," I'm not sure how they would react to that.This stuff, everything is taking more and more data, and everything is more and more connected to the cloud. The impact of something like that going down now is becoming totally crazy. There was a case in 2017 where S3 started getting a bit more latency than usual in U.S. East 1, in I think February of 2018, or something like that. There were cases where people couldn't turn the lights on in their houses because the management software was working on S3 and depending on S3. Expecting S3 to be indestructible. Last year, in November, Kinesis pretty much went offline as far as everybody else outside AWS concerend for about 15 hours I think. There were people on Twitter that they can't go back into their house because their smart lock is no longer that smart.And I think we are getting to places where there will be more need for compute on the edge. First of all, there's going to be a lot more demand for data centers and cloud power and I think that's going to keep going on for the next five, ten years. But then people will realize they've hit some limitation of that, and they're going to start moving towards the edge. And we're going from mainframe back into client server computing I think. We're getting these products now. I assume most of your listeners have seen one like all these fancy ubiquity Wi-Fi thingies that are costing hundreds of dollars and they look like pieces of furniture that's just sitting discretely on the wall. And there was a massive security breach yesterday published. Somebody took their AWS keys and took all the customer data and everything.The big advantage over all the ugly routers was that it's just like a thin piece of glass that sits on your wall, and it's amazing and it looks good, but the reason why they could do a very thin piece of glass is the minimal amount of software is running on that piece of glass, the rest is running the cloud. It's not just locking in terms of is it on Amazon or Google, it's that it's so tightly coupled with something totally outside of your home, where your network router needs Amazon to be alive now in a very specific region of Amazon where everybody's been deploying for the last 15 years, and it's running out of capacity very often. Not very often but often enough.There's some really interesting questions that I guess we'll answer in the next five, ten years. We're on the verge of IOT I think exploding because people are trying to come up with these new products that you wouldn't even think before that you'd have smart shoes and smart whatnot. Smart glasses and things like that. And when that gets into consumer technology, we're no longer going to have five or ten computer devices per person, we'll have dozens and dozens of computing. I guess think about it this way, fifteen years ago, how many computer devices were you carrying with yourself? Probably mobile phone and laptop. Probably not more. Now, in the headphones you have there that's Bose ...Jeremy: Watch.Gojko: ... you have a microprocessor in the headphones, you have your watch, you have a ton of other stuff carrying with you that's low-powered, all doing a bit of processing there. A lot of that processing is probably happening on the cloud somewhere.Jeremy: Or, it's just sending data. It's just sending, hey here's the information. And you're right. For me, I got my Apple Watch, my thermostat is connected to Wi-Fi and to the cloud, my wife just bought a humidifier for our living room that is connected to Wi-Fi and I'm assuming it's sending data to the cloud. I'm not 100% sure, but the question is, I don't know why we need to keep track of the humidity in my living room. But that's the kind of thing too where, you mentioned from a security standpoint, I have a bunch of AWS access keys on my computer that I send over the network, and I'm assuming they're secure. But if I've got another device that can access my network and somebody hacked something on the cloud side and then they can get in, it gets really dangerous.But you're right, the amount of data that we are now generating and compute that we're using in the cloud for probably some really dumb things like humidity in my living room, is that going to get to a point where... You said there's going to be a limitation like five years, ten years, whatever it is. What does the cloud do then? What does the cloud do when it can no longer keep up with the pace of these IOT devices?Gojko: Well, if history is repeating and we'll see if history is repeating, people will start getting throttled and all of a sudden, your unlimited supply of Lambdas will no longer be unlimited supply of Lambdas. It will be something that you have to reserve upfront and pay upfront, and who knows, we'll see when we get there. Or, we get things that we have with power networks like you had a Texas power cut there that was completely severe, and you get a IT cut. I don't know. We'll see. The more we go into utility, the more we'll start seeing parallels between compute and power networks. And maybe power networks are something that you can look at and later name. That's why I think the next cycle is probably going to be some equivalent of client server computing reemerging.Jeremy: Yeah. All right, well, I got one more question for you and this is just something where it may be a little bit of a tongue-in-cheek question. Because we talked it a little bit ... we talked about the merging of Lambda, and of Fargate, and some of these other things. But just from your perspective, serverless in five years from now, where do you see that going? Do you see that just becoming the main ... This idea of utility computing, on-demand computing without setting up servers and managing ops and some of these other things, do you see that as the future of serverless and it just becoming just the way we build applications? Or do you think that it's got a different path?Gojko: There was a tweet by Simon Wardley. You mentioned Simon Wardley earlier in the talk. There was a tweet a few days ago where he mentioned some data. I'm not sure where he pulled it from. This might be unverified, but generally Simon knows what he's talking about. Amazon itself is deploying roughly 50% of all new apps they're building on serverless. I think five years from now, that way of running stuff, I'm not sure if it's Lambda or some new service that Amazon starts and gives it some even more confusing name that runs in parallel to everything. But, that kind of stuff where the operator takes care of all the ops, which they really should be doing, is going to be the default way of getting utility compute out.I think a lot of these other things will probably remain useful for specialists' use cases, where you can't really deploy it in that way, or you need more stability, or it's not transient and things like that. My best guess is first of all, we'll get Lambda's that run for longer, and I assume that after we get Lambdas that run for longer, we'll probably get some ways of controlling routing to Lambdas because you already can set up pre-provisioned Lambdas and hot Lambdas and reserved capacity and things like that. When you have reserved capacity and you have longer running Lambdas, the next logical thing there is to have session stickiness, and routing, and things like that. And I think we'll get a lot of the stuff that was really complicated to do earlier, and you had to run EC2 instances or you had to run complicated networks of services, you'll be able to do in Lambda.And Lambda is, I wouldn't be surprised if they launch a totally new service with some AWS cloud socket, whatever. Something that is a implementation of the same principle, just in a different way, that becomes a default we are running computer for lots of people. And I think GPUs are still a bit limited. I don't think you can run GPU utility anywhere now, and that's limiting for a whole host of use cases. And I think again, it's not like they don't have the technology to do it, it's just they probably didn't get around to doing it yet. But I assume in five years time, you'll be able to do GPUs on-demand, and processing GPUs, and things like that. I think that the buzzword itself will lose really any special meaning and that's going to just be a way of running stuff.Jeremy: Yeah, absolutely. Totally agree. Well, listen Gojko, thank you so much for spending the time chatting with me. Always great to talk with you.Gojko: You, too.Jeremy: If people want to get in touch with you, find out more about what you're doing, how do they do that?Gojko: Well, I'm very easy to find online because there's not a lot of people called Gojko. Type Gojko into Google, you'll find me. And gojko.networks, gojko.com works, gojko.org works, and all these other things. I was lucky enough to get all those domains.Jeremy: That's G-O-J-K-O ...Gojko: Yes, G-O-J-K-O.Jeremy: ... for people who need the spelling.Gojko: Excellent. Well, thanks very much for having me, this was a blast.Jeremy: All right, yeah. And make sure you check out ... You mentioned Narakeet. It's a speech thing?Gojko: Yeah, for developers that want to build videos without hassle, and want to put videos in continuous integration, and things like that. Narakeet, that's like parakeet with an N for narration. Check that out and thanks for plugging it.Jeremy: Awesome. And then, check out MindMup as well. Awesome stuff. I've got all the stuff in the show notes. Thanks again, Gojko.Gojko: Thank you. Bye-bye.

In this episode of Semaphore Uncut, we talk to Gojko Adzic, specialist in agile and lean quality improvement. We talk about how to make truly valuable software products: addressing real needs rather than all requests and establishing quick feedback loops by observing behavior change. Gojko also shares how he has kept his passion for software alive. We hear how he made space to learn and experiment and how he guards his autonomy.Gojko is a frequent speaker at software development conferences. He is also the author of Specification by Example and other books.Key takeaways:A developer-customer communication anti-patternSolve for needs, not featuresBehavior change: a rapid feedback loopData over opinionBooks for budding product designersKeeping the passion aliveThe joy of autonomyEven 'failed' experiments produce learningAbout Semaphore UncutIn each episode of Semaphore Uncut, we invite software industry professionals to discuss the impact they are making and what excites them about the emerging technologies.

FROHES NEUES JAHR! Ganz spontan haben wir uns entschieden doch noch eine Folge im Jahr 2020 zu machen: Professor vanDusen fällt unter die Räuber. Und weil es eine besondere Folge ist haben wir uns gleich 2 Gäste dazu geholt: Zum einen kommt der Mike wieder in den Podcast, zum anderen haben wir unsere kleine Schwester motivieren können zu uns zu stossen. Und als besonders Schmankerl haben wir dieses mal unser Zoom Meeting aufgenommen und ihr könnt es auf Youtube (Link unten. Ich bin besonders stolz auf das Intro) ansehen. Was uns diesmal beschäftigt hat: Meine Gattin ist blutarm. Zahlt Thomas Cook das Lösegeld? Gibt es Konsulate in kleinen Fischerdörfern?Was sind das eigentlich für schlechte Räuber? Die essen echt Kutteln? Annika mag kein Lamm. Wozu hat der Räuberhäuptling eigentlich einen Vorkoster? Lässt Dimitri auf dem Löffel in seinem Mund dann so ne grosse Graupe zurück und der Räuberhäuptling isst die dann? Kann man so einfach so ne kleine Gelatinekapsel mit Füllung herstellen? Und warum nimmt der Tafelspitz eigentlich so viel Cyankali mit? Was sind die christlichsten Tötungsarten? Würde der Räuberhauptmann wirklich nach Bittermandel riechen? Gojko ist aber schon schnell zu beruhigen. Wieviele Graupen sind eigentlich auf so einem Teller? Wer kocht Säuren ausser Holger? Aber das war es noch nicht: Die Gelatine-Frage lässt uns nicht los. Holger nennt sich jetzt dann Hulger, sagt Erok, was Unnika nicht so lustig findet wie Basti (Insider). Tafelspitz kannte Dimitri vorher, oder nicht? Aber auf alle Fälle: Warum macht der das alles mit? Hatten die Kutteln was mit dem Mordplan zu tun? Hatte Dimitri patriotische Gefühle? 00Tafelspitz? Was war der für ein Beamter eigentlich? Erik ist voll der Spindoktor. Wir finden unsere Ideen irgendwie besser.Mike hätte eh einfach kurzen Prozess gemacht. Folgt und kommentiert gerne auf Instagram (https://www.instagram.com/vandusen_podcast/) oder unserem Blog (https://zweipluszweiistvier.wordpress.com/)!

Gojko reveals the amazing scale and scope of international trade in the ancient Middle East. And the incredible detail in which we can study it. The Assyrian trade network was not the exception we used to think it was. The traders’ business records document a system that has much to offer wider historical study. 2:39 what is trade?5:10 about the Old Assyrian Colony Period9:31 what the ancient archives tell us12:49 was Assur normal or exceptional?17:44 the significance of the scope and scale of the trade21:52 who were these traders?30:43 the relation between trade and political organisation Academia: https://harvard.academia.edu/GojkoBarjamovic University page: https://nelc.fas.harvard.edu/people/gojko-barjamovic Music by Ruba Hillawi Website: http://wedgepod.orgYouTube: Email: wedgepod@gmail.com Twitter: @wedge_pod Patreon: http://Patreon.com/WedgePod

Diesmal mit: Corona, Zahnschmerzen, Zombies und Steuererklärung.

Here is our 27th episode with host Joshua Proto and guest Gojko Adzic. Gojko is a Partner at Neuri Consulting and a premier serverless author! In this episode here about: -How Serverless can be a liberating structure -The usefulness of multi-versioning toolkits and their enterprise use cases -Exciting new projects like Video Puppet -And much more! With over an hour of content, it’s our biggest podcast yet! And if you like this episode please go to our website to hear the full catalogue where it is always free: talkingserverless.io --- Send in a voice message: https://anchor.fm/talking-serverless/message

- Pakleni Tesini treninzi u Vojvodini - Prelazak i godine provedene u Partizanu - Odličan savet Šefika i nastavak karijere u Kotoru - Pritisak na Olimpijskim Igrama u Riju

Mesél a múlt: 80 éves Gojko Mitic, egy partizán fia, tornatanár majd dublőr, aztán NDK filmmsztár. Katona Csaba, történész. Tőzsdenyitás: Deák Dávid, az Equilor Befektetési Zrt. üzletkötője. Kultmogul: ki volt a “Ventillátor kisasszony” és miért érdekes élete és hagyatéka? Május végén volt 100 éve annak, hogy megszületett Ottrubay Melinda, az egyedüli magyar prima balerina assoluta, az Operaház csillaga, és Esterházy hercegné.  Borbély Zsuzsa, a Fidelio vizuál, film, és könyv rovatvezetője.

Translated from the Serbian by Djordje Krivokapic.A Poem A Day by Sudhanva Deshpande.Read on May 10, 2020.Art by Virkein Dhar.

Mrknete na nas prvni Livestream, ktery budeme vydavat s Tomasem Pribylem. Jak rikam prvni :-) Takze jsme si prosli porodnimi bolestmi, ale nakonec se povedlo prvni dil odvysilat a natocit. Diky Livestreamu mame moznost vykryt casove omezeni a tedy vyzpovidat spoustu zajimavych ale jinak casove zaneprazdnenych kolegu. Stejne tak i vy se budete moci do streamu pripojit a polozit otazky. Host: Lucie Nova Twitter: @lucie_nova Konzultantka na volné noze. Aktuálně pracuje pro Českou spořitelnu jako projektová test leadka. Školí IT procesy pro Českou společnost pro jakost. Fanynka kvalitního softwaru, tramvají a Star Treku. TESTING UNITED 2019 https://testingunited.com/home/tickets/
 TESTING UNITED 2018: Tomasz Dublikowski - Super QA of the future https://www.youtube.com/watch?v=Mrl7ot2CVRA
 Lisa Crispin
 https://www.mabl.com/blog/practical-uses-for-machine-learning
 Lisi Hocke https://www.lisihocke.com/ Gojko's blog https://gojko.net/ Pokud se Vám díl líbil, dejte lajk a odebírejte - aspoň mě více namotivujete :-) YouTube youtu.be/82MIjbgld9A iTunes https://itunes.apple.com/cz/podcast/test-stack/id1344559184?l=cs&mt=2
 Instagram www.instagram.com/rdpanek/
 Twitter twitter.com/RDPanek
 LinkedIn www.linkedin.com/in/rdpanek

Guest Bio: Gojko is a partner at Neuri Consulting. He is the winner of several awards, including the 2016 European Software Testing Outstanding Achievement Award and the Jolt Award for his book, Specification by Example. Gojko is also a frequent speaker at software development conferences.   Episode Description: In this episode, Phil chats with Gojko Adzic about experiencing the joy of coding and programming, but also recognizing the importance of seeing the big picture when it comes to projects. Gojka highlights this by advising people work “close to the money” to gain a better understanding of how customers use the products he makes, and how his first startup went bankrupt when he got too wrapped up in tracking technical effort instead of product value. Still, he says he can’t imagine doing anything other than working in IT.   Key Takeaways:   (1.00) Phil kicks off the interview by asking Gojko more about himself. Gojko talks about writing books, how he got his start developing software, but he always wanted to do more than just “sitting in a development box,” as he puts it. He prefers working on projects end-to-end.   (3.21) Phil follows up by asking Gojka for a unique career tip people might now know. Gojka answers with the advice: “stay as close to the money as possible.” He goes on to say that he feels like today, IT is often extremely divorced from the customers and users that they are actually making things for. It becomes hard to tell if your work is having an actual impact. Staying close to the money means making sure that the things you do serve a purpose.   (7.45) Phil moves on, asking Gojka about the worst experience of his IT career, and Gojka jokes that it’s difficult to pick the “worst.” He says the one that made him feel the worst but was the most important learning experience came when he was a CTO of a startup and that they were good at the technical side of things but had no idea how to calculate value and properly run a business and so they went bankrupt. He was way too focused on measuring effort and not value.   (13.06) Phil switches things up and asks Gojka about his greatest career success so far, and he says that he hopes he hasn’t made his greatest success yes. But he’s very proud of a project called Mind Map and that it has helped him rediscover the joy of coding.   (15.00) Phil then asks Gojka what excites him the most about the future of the IT industry, and he says software specifically is the closest thing to magic there is, and that it’s incredible that people can make something that has such a huge impact on the real world, essentially out of thin air.   (15.50) Phil starts the Reveal Round by asking Gojka what motivated him to pursue a career in IT, to which he answers that he never wanted to do anything else, quite literally from the age of six onwards.   (17.01) Next, Phil asks Gojka for the best career advice he’s ever received. Gojka says it’s probably something he read in one of The Pragmatic Programmer books, which was: “don’t say no, offer options.” Instead of saying that something isn’t possible, try to come up with options for things you CAN do instead.   (18.10) Phil then questions Gojka as to what he would do if he were to begin his IT career all over again now, and Gojka answers that he never really wanted to do anything different, but that he would try to switch jobs faster to learn as much as possible about as many different things as he could.   (19.01) On the subject of current career objectives, Gojka talks about writing a new book that’s actually about a technique that can be used to solve the problem of his worst career moment.   (20.03) Phil asks what non-tech skill Gojka has found the most useful during his career, and he responds that he doesn’t really differentiate between what’s technical and non-technical, but that the idea of selling value and not time was a non-tech thing he learned that has made a major impact on his career.   (21.31) Phil wraps things up by asking Gojka for any parting words of advice for the listeners and he advises people to not waste time working on things that they don’t really care about or find important and that they should be able to work on creating things that bring them joy.   Best Moments:   (1.15) Gojko: “I tend to write books to download the stuff in my brain so I can leave more spare capacity for new things.”   (5.48) Gojko: “My career advice for people starting here would be to figure out where the money is and stay as close as possible to that because that just cuts through the whole bullshit that most people shouldn’t really care about.”   (7.24) Phil: “I think it’s all about what the end purpose is, rather than the actual solution that gets you there.”   (12.50) Gojka: “IT’s really nice as an industry because you can make stupid mistakes and learn from them and then kind of pull yourself up.”   (14.48) Gojka: “If people feel that their work is dull they should build their own product.”   (21.56) Gojka: “You can spend a lot of time building stupid systems nobody cares about and you shouldn’t be wasting your life on that. Programming should be a joyful activity.”   Contact Gojko Adzic: Blog: www.gojko.net LinkedIn: https://www.linkedin.com/in/gojko/ Twitter: https://twitter.com/gojkoadzic @gojkoadzic Latest Book: https://www.amazon.com/Humans-Vs-Computers-Gojko- Adzic/dp/0993088147    

  Product Owners think a lot about delivering value and how best to do that. One way that can help focus those efforts is a technique from Gojko Adzic called Impact Mapping.  On this episode, Gojko joins us to talk about the basic concepts, some tricks to asking better questions while putting one together, and ways to help facilitate better collaboration. It’s a very interesting area and skill for PO’s to learn and after listening, you should be able to start creating one yourself.           Feedback: twitter - @deliveritcast email - deliveritcast@gmail.com   Links: PO Coaching and Consulting - seek taiju Gojko Adzic @gojkoadzic https://gojko.net/ Gojko Adzic - Impact Mapping with Innovation Games Gojko Adzic - Product Owner Key Skills – Impact Mapping, Story Mapping and Valuable User Stories Mark Schwartz - The Art of Business Value Ronny Kohavi - Online Experimentation at Microsoft Chris Williams - Why We Can't Stop Overcomplicating Agile  

Zu Gast war diesmal Tanja (@fschmidt77), die über jede Menge Männer sprach: Über große und starke wie Sven und Kai, kleine wie Ben, frisurbewusste wie Gojko, junge Hüpfer wie Fiete und auch über die, die fehlen - wie Hermann. 00:00:00 Intro 00:00:16 Begrüßung 00:01:52 Rückblick Bremen 00:11:40 Vorschau Mainz 00:18:53 Abseits 00:29:18 Stadiongeschichten 00:37:51 Geburtstagskinder 00:43:56 Gastarbeiter 00:49:31 Ulrich des Jahres 00:56:57 Quiz Die Musik kommt von terrasound.de. Bitte bewertet mich bei iTunes. Meinen Podcast "bälle und bücher" gibt's bei iTunes oder hier: http://baelleundbuecher.podigee.io Oder hier: https://kunterbuntesbuecherregal.wordpress.com/podcast/ Amazon Wunschzettel: https://t.co/63N5NVibI6

Präsidenten & andere Häuptlinge. Im Interview: Der Erfinder der SIMPSONS, die Trumps Wahlsieg schon im Jahr 2000 prophezeiten: Matt Groening. Auch Interview: Bundespräsident Joachim Gauck und DDR-Oberindianer Gojko Mitic. DAS POLITISCHE LIED: "1000 Days, 1000 Songs" gegen Präsident Trump. ZEHN&EINS: Was von den 10 deutschen Bundespräsidenten blieb - und was von Gauck bleiben wird.

Präsidenten & andere Häuptlinge. Im Interview: Der Erfinder der SIMPSONS, die Trumps Wahlsieg schon im Jahr 2000 prophezeiten: Matt Groening. Auch Interview: Bundespräsident Joachim Gauck und DDR-Oberindianer Gojko Mitic. DAS POLITISCHE LIED: "1000 Days, 1000 Songs" gegen Präsident Trump. ZEHN&EINS: Was von den 10 deutschen Bundespräsidenten blieb - und was von Gauck bleiben wird.

DocPhil fährt mit seinem Sohn ins El Dorado Templin, eine Westernstadt in Brandenburg, um Gojko Miti? zu treffen, der irreführender Weise oft als "Winnetou des Ostens" bezeichnet wird.Gojko Miti? entpuppt sich als sehr angenehmer Zeitgenosse. DocPhil trifft noch ein bewaffnetes Mitglied der Western-Community und wird Zeuge einer Western-Stunt-Show. Abschliessend noch der Link zum Programm-Hinweis: Die "Lage der Nation", der wöchentliche Polit-Podcast mit Philip Banse und Ulf Buermeyer. (bei iTunes)

In der Episode „Hals- und Beinbruch" (AT) geht es um den Mord an der erfolgreichen Springreiterin Katrin Seeberger, die tot auf dem Reitplatz gefunden wird. Sie ist vom Pferd gestürzt und wurde dann erstickt. Unter Mordverdacht beim „SOKO Stuttgart"-Team unter Leitung von Kriminalhauptkommissarin Martina Seiffert (Astrid M. Fünderich) geraten u.a. ihr schärfster Konkurrent Claudius von Kampen (Wayne Carpendale), ihr Pferdepfleger Ortwin Michalsky (Gojko Mitić), ihre beste Freundin Tara Leonhardt (Jördis Richter) und ihr Trainer Nick Robertson (Robert Seeliger)...

This month we bring you an interview with Gojko Adzic. Gojko is a frequent speaker at leading software development and testing conferences and runs the UK agile testing user group. Over the last eleven years, he has worked as a developer, architect, technical director and consultant on projects delivering equity and energy trading, mobile positioning, e-commerce, online gaming and complex configuration management. He is the author of several books and articles. In 2012 his book Specification by Example received the Jolt award. To celebrate the Jolt Award, the publisher of Spec by Example is offering our podcast listeners a 37% discount on Specification by Example. Note that Goiko has recently published a new book Impact Mapping: Making a big impact with software products and projects, which we did not get around to discussing in this interview. Follow Goiko on twitter via @goikoadzic or on his site on http://gojko.net/ This interview was recorded on the 8th of oct 2012 at the Holiday Inn Express in Amsterdam. Interview by @freekl and @felienneAudio post-production by @mendelt Links for this podcast: Book:Specification by Example, Gojko Adzic, 2011. Book:Bridging the Communication Gap ('The Blue book'), Gojko Adzic, 2009 Article: Redefining software quality, Gojko Adzic, 2012 Book: Made to Stick, Chip and Dan Heath, 2007

Mitić entstammt einer Bauernfamilie aus dem Dorf Strojkovce, einem Ortsteil der Stadt Leskovac im Süden Serbiens, an der Veternica. Nach seiner Schulausbildung, bei der er auch frühzeitig in Deutsch unterrichtet wurde, began Mitić Sport zu studieren. Während seines Studiums knüpfte er erste Kontakte zum Film, da zu dieser Zeit in Jugoslawien viele internationale Filme produziert wurden, deren Komparsen hauptsächlich Studenten der Belgrader Sporthochschule waren. 1963 erhielt er eine winzige Rolle in dem von Artur Brauner produzierten Karl-May-Film Old Shatterhand . Beeindruckt von seiner athletischen Erscheinung, ermöglichte man ihm, nach der Rialto-Produktion Winnetou 2 im nächsten Film der Serie in Unter Geiern , eine erste große Hauptrolle als Häuptlingssohn Wokadeh zu übernehmen. Hier erschien sein Name im Abspann noch eingedeutscht als „Georg Mitic“. So verkörperte er viele Indianer. Was Mitić heute macht, erfahrt Ihr im Promigeflüster. Infos unter: www.gojkomitic.de