30. 100 Steps To Product Delivery Nirvana

Kevin Callahan on Engineering Culture by InfoQ, Matt Wallaert on The Product Science Podcast, Mirco Hering on Troubleshooting Agile, Ryan Ripley on Agile FM, and Adam Tornhill on Maintainable. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email [email protected]. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting February 3, 2020. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. KEVIN CALLAHAN ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Kevin Callahan with host Shane Hastie. Kevin helps people solve complex problems together. Sometimes that looks like Scrum, Kanban, and technical practices, and sometimes that looks like organizational development and strategy. Shane asked about positive organizational development. Kevin says that positive organizational development is an interconnected body of work with the core idea that true sustained change doesn’t happen when we simply try to fix things that are weak or broken. Positive change suggests that you go to the places that are already good and you amplify them and the places that weren’t working so well cease to be relevant. Shane asked what this looks like in practice. Kevin says that, because he is actively inviting people into the room and looking to see what the group already knows together, he finds it energizing and refreshing and people lean into it and feel like they belong there. Shane asked how someone in a position of influence who wanted to create some kind of change in their organization would approach the organization and their people. Kevin likes to start with open questions that get the people to imagine everything was right in the company and ask what people are  doing differently, what customers are saying, what quality is like, and what stories people are telling each other when they don’t think anyone is listening. These positive questions get people to imagine what could be and starts in motion the change effort that makes it possible to achieve the change. You may get answers like “I only want to work four hours a day,” or, “I want six months of paid vacation,” but eventually you may get answers like, “I really wish I had the opportunity to learn more things.” Shane connected Kevin’s ideas to Dave Snowden’s notion of sense-making and asked how you make sense from non-viable statements like, “I want to work four hours a day,” so that you arrive at more viable questions like, “How do I stay at home more?” Kevin says that instead of reacting to non-viable requests by blowing them off, ask follow up questions to build a bigger narrative. You could ask clean language questions like, “What kind of four hour workday? What would come before your four-hour workday? What would come after?” This builds a bigger narrative that helps you respect something that is valuable to this person while still respecting the organization’s collective needs. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/kevin-callahan-on-positive-organisational-design-complex/id1161431874?i=1000462364585 Website link: https://soundcloud.com/infoq-engineering-culture/kevin-callahan-on-positive-organisational-design-and-complex-systems MATT WALLAERT ON THE PRODUCT SCIENCE PODCAST The Product Science Podcast featured Matt Wallaert with host Holly Hester-Reilly. Trained as a behavioral scientist, Matt is Chief Behavioral Officer at Clover. He says he is always fascinated by outliers, those customers that are using his products in unconventional ways. He says that having conversations with these users can sometimes push you in startling directions to build new things or think in different ways.  The behavioral science team is given behavioral outcomes that the company needs to accomplish such as, “everybody needs to get a flu shot,” and figure out what needs to be done to make it happen. They look at two groups of outliers: people who consistently did it and suddenly stopped and those that consistently did not do it and suddenly started. They found that people who get the flu shot for the first time often do so because of the birth of grandchild. This led them to start a flu shot campaign that was personalized to your personal health goal. Instead of saying, “You should get the flu shot for you,” it often said, “You should get it so you don’t get your wife sick, so you don’t get your grandchild sick, or so you don’t get your church congregation sick.” He contrasted this collectivist form of motivation with products like Spotify that are all about benefitting the user directly. Expanding the set of motivations we examine to include people’s willingness to do things on behalf of another person, on behalf of a culture, or on behalf of an identity, he says, is undeveloped in modern product management. If there is a number one product hobgoblin of early founders, it is their belief that the pros outweigh the cons. They massively overweight the pros and massively underweight the cons. But lately, there have been a whole host of startups that are not about providing additional value but simply about minimizing costs, and not just economic costs but also mental attention costs. Finance companies think about their products as “share of wallet”. For, say, American Express, of the financial transactions that a customer performs, they want to know how much of that is going on an American Express card. Their job is to maximize this share of wallet. Similarly, Facebook attempts to maximize share of attention. This is an impoverished view of product-building. Companies like this are leaving off the “I” in ROI. One of the problems of the “share of attention” view of the world, is that it means everyone is in competition with everyone else. Even products that seem far apart, such as a product in the exercise space and one the video game space, are competing for share of attention. Matt thinks people are going to get smarter about where they spend their attention. A whole new product class will come out around automating the things we don’t care about. The rise and fall of Blue Apron, he says, was a dramatic characterization of the misunderstanding of automation. Blue Apron sold the world on automated food. That is not what Blue Apron is. They went on to talk about the desire for statistical significance in every experiment and how the context of the experiment drastically affects how much certainty is really needed. He talked about how most quantitative analysts who see an intervention that is measured to work 80% of the time in the sample of the population measured would say, “I got nothing,” and end the experiment. So Matt says, “Let me tell you about this intervention: It is a tiny pill, dissolves in your mouth, has no side effects of any kind, costs a penny to produce, tastes like unicorns and rainbows, and instantly cures all forms of cancer forever. Maybe we should further investigate this intervention.” He compared his book Start At The End to Thaler and Sunstein’s Nudge. His book is more about how to create a process, a team, and an organization around behavioral science approaches. Instead of running his team as a research organization, he runs it like a factory. This makes it easier for an executive to understand how it all works. He says his book is more a handbook. Half the book is how you go about building the intervention design process and the other half is more advanced topics. He is seeing it being taught in college courses in disparate programs, including business administration, marketing, and implementation science. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/matt-wallaert-hypothesis-great-product-teams-use-behavioral/id1451623431?i=1000462456956 Website link: https://anchor.fm/product-science-podcast/episodes/The-Matt-Wallaert-Hypothesis-Great-Product-Teams-Use-Behavioral-Science-to-Build-Products-That-Create-Change-ea3s54 MIRCO HERING ON TROUBLESHOOTING AGILE The Troubleshooting Agile podcast featured Mirco Hering with hosts Douglas Squirrel and Jeffrey Fredrick. Mirco is the author of DevOps for the Modern Enterprise. They talked about dogmatism. Marco says that he sees Agile and DevOps as a toolbelt to solve problems in organizations but not everyone he works with thinks this way. One of the Agile coaches he once worked with said on his first day, “You shouldn’t call these user stories. They are PBIs (product backlog items).” Mirco asked, “What value would that provide? Nobody was confused about the term user story. If anything, you are now adding confusion.” He sees this kind of dogmatism in many organizations. He says that, for him, being pragmatically agile always comes down to identifying the next experiment and having rigorous continuous improvement. Squirrel asked Mirco how one can help companies that aren’t familiar with agile ideas to avoid the dogmatism and make the pragmatic choices that improve their process. Mirco believes it starts with value stream mapping. This gives you a good visual of the overall process and you can identify bottlenecks, quality holes, and things that take too long. Jeffrey brought up the book Crossing The Chasm and how the early majority change because they don’t want to be left behind and the late majority change because the new behavior is the standard. He asks how, when this is their motivation, do you help the business to get from “we need to be Agile to be Agile” to “having a purpose.” Mirco says that, very early on, you need to ask, “How will we know we’ve been successful?” Mirco sees companies at conferences describe a world where they can do forty deployments a day and have all employees singing and dancing everyday. They are not anywhere close to this ideal. They need to figure out how to see in two months time that they are making progress. They should be able to ask, “What does the business want to do that it can’t do now.”  As a consultant, the very first thing you do is listen. Often they start to tell you some stories. Then you start trying a couple of ideas. You could do a bit of decoupling on the architecture or a bit of Agile coaching on a failing Agile project. You have a large tool belt of tools to choose from. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/devops-for-the-modern-enterprise/id1327456890?i=1000462577701 Website link: https://soundcloud.com/troubleshootingagile/devops-for-the-modern-enterprise RYAN RIPLEY ON AGILE FM The Agile FM podcast featured Ryan Ripley with host Joe Krebs. Ryan was on to talk about the book he co-authored with Todd Miller called, “Fixing Your Scrum.” He says that the book came out of a conversation he had with Todd two years ago about the Scrum anti-patterns that they were seeing in the wild over the past twenty years and how the two of them, as consultants, solve them. Most Scrum books are very theoretical. Ryan and Todd, by contrast, spent only one page on the Scrum framework and jumped right into advanced topics. Joe brought up that Scrum tends to turn into something robotic and oriented around checklists. Joe considers this form of Scrum to be lifeless and low in energy. He finds that nobody leaves the events with a smile on their face and he wonders how the book would help such people. Ryan says that such mechanical Scrum is very common and it is because the principles and values are lacking. It becomes rote and legalistic. He says that he and Todd don’t care that much about Scrum. Instead, they care about empiricism and want to bring forward transparency, inspection, and adaptation, and use the Scrum values of focus, openness, courage, commitment, and respect to make adaptations to products as needed to deliver the right thing at the right time to the right customer. Without having the values in place, empiricism can’t work. Companies have gone to the mechanical version of Scrum to avoid empiricism. Empiricism is table stakes now. Twenty years ago, empiricism was a cute idea that people could dismiss because the blue chip companies were fat, happy, and dumb. Their problem was success. Today, no matter what industry you’re in, banking, taxi cabs, or real estate, there is a startup looking to destroy your market. He asks, “Who would have ever thought the taxi cab industry would be upended by Uber and Lyft? Who would have ever thought that the largest real estate company in the world would own zero real estate and be Airbnb?” Joe asked about the sentence, “The Scrum Master’s work is never done.” Ryan says that the statement comes from the rapid rate of change today. He and Todd believe that the majority of times a Scrum team fails, it is because a Scrum Master is settling. The Scrum Master is tolerating organizational or team impediments.  The reason a Scrum Master’s job is never done is that those impediments morph and change and emerge constantly. Ryan has yet to see a company where nobody leaves, markets don’t shift, and budgets don’t become constrained. As Scrum Masters, our role is to help organizations make sense of the complexity through the use of the Scrum framework and to help teams refocus and reshape what they could and should be doing to serve a customer. Ryan says nothing about the Scrum Master role is about the Scrum Master. When Ryan transitioned from a project manager to a Scrum Master, this part was difficult for him. Back when Ryan was a project manager, everything was about him: he was the one making the decisions, driving people to a date, or getting in front of boards of directors and making a speech. As a Scrum Master, we are in the back of the room watching the dev teams show off their software. None of this is about the Scrum Master. The job is to serve others. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ryan-ripley-agile-fm/id1263932838?i=1000462512766 Website link: https://agile.fm/agilefm/ryan-ripely ADAM TORNHILL ON MAINTAINABLE The Maintainable podcast featured Adam Tornhill with host Robby Russell. Robby started out by asking Adam about the common traits of a maintainable solution. Adam first likes to see the solution optimized for understanding. Second, he wants to see alignment between the architecture, the team boundaries, and the way the system evolves. Last, he wants the capability to deliver anytime with known quality. In terms of team boundaries, Adam wants to avoid having multiple teams working in the same parts of the code for different reasons because that has a high correlation to quality issues and makes it hard for individuals to maintain mental models of the system. He says you want clear operational boundaries between teams but then you also want each team’s knowledge boundary to be slightly wider so that you are familiar with other parts of the system and know other teams’ members as people. Robby asked what about a separation between a team working on new features and another fixing bugs. Adam is not a fan of that form of separation because it cuts out an important feedback loop. Robby asked what other developers get wrong when discussing technical debt. Adam says that many developers call any code that’s bad technical debt, but to Adam, it is not technical debt unless you have to pay interest on it. With a high degree of technical debt, you tend to see lots of effects on the product roadmap, you get longer and longer lead times, and your end users experience defects that take a long time to fix. Robby asked about Adam’s book on behavioral code analysis, Software Design X-Rays. In behavioral code analysis, the emphasis is placed more on the organization and the developers building the code than on the code itself. You analyze using measurements from version control data and project management data and it is used to prioritize technical debt or reason about social factors of software development projects. Some examples are detecting knowledge gaps in the code, code written by developers no longer present, or uncontrolled coordination needs between different developers in the code. Robby asked what motivated Adam to write the book. Adam says that Software Design X-Rays follows in the tracks of his first book, Your Code As A Crime Scene, which was written to share techniques Adam had been using in his consulting work. The theme for both books is, “How can you make it easier and cheaper to maintain your software?” There are several patterns he uses often. One is the concept of hot spots, which help identify complicated code that we work with often. The data shows that any application can have its hot spots narrowed down to two or three percent of the codebase. This is a positive message that tells us we don’t need to rewrite whole programs but can make big improvements by changing only a small percentage of the product. Robby asked how to prioritize work on technical debt reduction. Adam says to prioritize the most complex modules using hot spot analysis. With slightly more advanced analysis, you can get hot spots down to the function level and get quick wins within days. For your initial refactorings, you should use techniques like mob refactoring to help spread knowledge of how to attack these kinds of problems and get everyone to align on the approach. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/adam-tornhill-prioritizing-technical-debt-behavioral/id1459893010?i=1000463144606 Website link: https://maintainable.fm/episodes/adam-tornhill-prioritizing-technical-debt-with-behavioral-code-analysis-yigwD2Ga LINKS Ask questions, make comments, and let your voice be heard by emailing [email protected]. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website: https://www.thekguy.com/