100 Steps To Product Delivery Nirvana

The true culture of a place, impoverished views of product-building, Agile for Agile’s sake, avoiding empiricism, and the ease of identifying bad code.

Monday, February 3, 2020

On Monday, February 3, I shared a link to an episode of the Engineering Culture by InfoQ podcast featuring Kevin Callaghan 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. As he says in the quote, the things people tell each other in confidence is the true culture of the place.

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.

Wednesday, February 5, 2020

On Wednesday, February 5, I shared a link to an episode of The Product Science Podcast featuring 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. As he says in the quote, 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.

Friday, February 7, 2020

On Friday, February 7, I shared a link to an episode of the Troubleshooting Agile podcast featuring 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 tool belt 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.” As Mirco says in the quote, 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.

Monday, February 10, 2020

On Monday, February 10, I shared a link to an episode of the Agile FM podcast featuring Ryan Ripley with host Jochen 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. As he says in the quote, 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.

Wednesday, February 12, 2020

On Wednesday, February 12, I shared a link to an episode of the Maintainable podcast featuring 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 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.

Adam gave his definition of technical debt. He says that, when he speaks more freely, he uses the term to address any code that lacks in quality and has an impact on the business. Robby asked how he ascertains whether code is bad or not, which led to what he said in the quote.

They talked 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.